Sorted based on the number of comments given to others' PRs, but also showing comments on own PRs and other comments given. Updated weekly.
[This page was last updated on Mar 29 2021]
@w2vgd (128 comments)1 (commented on others PR)
Should we use the actual website links instead of the link to the markdown file?
2 (commented on others PR)
Should there be a corresponding w-yuchen.png image uploaded as well?
3 (commented on others PR)
Should there be 2 formats for the sort command as well?
4 (commented on others PR)
Perhaps this should be updated too
5 (commented on others PR)
Should this be left out because the use cases are supposed to show only what the user can see?
6 (commented on others PR)
Similar to the previous comment
7 (commented on others PR)
I guess this is down to the implementation already.
Will you want to
execute the edit command even if there are erroneous fields or
abort the whole command entirely and show an error?
8 (commented on others PR)
The add command follows number 2 for now.
Good point raised, we can follow up on this discussion about which format we want with the other team members.
9 (commented on others PR)
I think this may have been left out by mistake
10 (commented on others PR)
Rmb to update this javadoc
11 (commented on others PR)
I think this may be removed as it is handled above
12 (commented on others PR)
All the EditPropertyCommand.EditPropertyDescriptor can be simplified to just EditPropertyDescriptor since EditPropertyDescriptor is an inner class of EditPropertyCommand
13 (commented on others PR)
Perhaps this should be removed
14 (commented on others PR)
Remember to update all the javadocs too
15 (commented on others PR)
Maybe can do a import seedu.address.logic.commands.EditPropertyCommand.EditPropertyDescriptor; on top so that you can directly use EditPropertyDescriptor instead of the whole verbose type
16 (commented on others PR)
Rmb to change this javadoc
17 (commented on others PR)
Rmb to update this variable name
18 (commented on others PR)
Rmb to update this variable name
19 (commented on others PR)
Rmb to update this javadoc
20 (commented on others PR)
Rmb to update this javadoc
21 (commented on others PR)
Rmb to update this javadoc
22 (commented on others PR)
Rmb to update this javadoc
23 (commented on others PR)
Rmb to update this javadoc
24 (commented on others PR)
Rmb to update this javadoc
25 (commented on others PR)
Rmb to update this javadoc
26 (commented on others PR)
Rmb to update this javadoc
27 (commented on others PR)
Should the message_usage be from FindPropertyCommand instead?
28 (commented on others PR)
Rmb to update this javadoc
29 (commented on others PR)
Rmb to update this javadoc
30 (commented on others PR)
Should this description should include the appointments also?
31 (commented on others PR)
Perhaps this part should be under the switch clause instead
32 (commented on others PR)
Should this two be getTypicalAppointmentBook() instead?
33 (commented on others PR)
Should this two be getTypicalPropertytBook() instead?
34 (commented on others PR)
Should this two be getTypicalAppointmentBook() instead?
35 (commented on others PR)
Should this two be getTypicalPropertyBook() instead?
36 (commented on others PR)
Ok thanks
37 (commented on others PR)
I think it is?
38 (commented on others PR)
Should this two be getTypicalAppointmentBook() instead?
39 (commented on others PR)
Should this be getFilteredAppointmentList() instead?
40 (commented on others PR)
Don't change this because the time is supposed to be displayed as "9:00AM" and not "9:00am"
41 (commented on others PR)
Rmb to update this to getTypicalPropertyBook()
42 (commented on others PR)
Can simplify to just SortAppointmentDescriptor instead of SortAppointmentCommand.SortAppointmentDescriptor
Same goes for other instances in this whole file
43 (commented on others PR)
I think this should be sorted in %1$ending order instead right? Because its ascending and descending.
44 (commented on others PR)
Will this throw an error if user did not pass in either asc or desc in the command? Is the asc/desc supposed to be optional instead?
45 (commented on others PR)
Think there is a typo here. This whole file is using EditPersonDescriptor instead of SortAppointmentDescriptor.
But I think for SortAppointmentTest, the testing should be of a different format too right?
46 (commented on others PR)
Oops right!! My bad.
47 (commented on others PR)
Ohh, ok sure
48 (commented on others PR)
Remember to update the UG in this case
49 (commented on others PR)
Ok, do rmb to update it in future
50 (commented on others PR)
Rmb to update this javadoc
51 (commented on others PR)
Any reason for this change?
52 (commented on others PR)
I think it will be neater to create an empty constructor in Client class.
53 (commented on others PR)
There will be an extra ; in the toString of Property when both the client information and tags are printed
E.g. Client Asking Price: $800,00;; Tags: [4 bedrooms]
54 (commented on others PR)
Rmb to update this javadoc
55 (commented on others PR)
Is there a reason for using .withName(VALID_NAME_BURGHLEY_DRIVE)?
56 (commented on others PR)
Is there a reason for using .withName(VALID_NAME_BURGHLEY_DRIVE)?
57 (commented on others PR)
Just a suggestion: Would you like to consider using the ArgumentTokenizer class here?
58 (commented on others PR)
Perhaps this can be changed to:
"Parameters: [KEYWORD]... [pl/UPPER_PRICE_LIMIT] [pm/LOWER_PRICE_LIMIT]"
instead and put the note on inclusive in the description? So that it aligns with our command format of replacing the uppercase characters in the command format with user input.
59 (commented on others PR)
Rmb to update this to property book
60 (commented on others PR)
I think it may be better to standardize your prefixes by adding a space behind "proceed" and "cancel" as as well
61 (commented on others PR)
Have you considered the use of forward slashes in these new prefixes? Such as new/, proceed/ and cancel/
What may be some of the reasons you choose not to use them?
62 (commented on others PR)
Rmb to remove this extra line
63 (commented on others PR)
Rmb to remove this extra line
64 (commented on others PR)
Maybe this description can be more descriptive?
65 (commented on others PR)
Rmb to update this javadoc
66 (commented on others PR)
Rmb to update this javadoc
67 (commented on others PR)
Is there a reason for this change? Have you tested with resizing the app? Because I am not sure if this will affect when the user resize the app (e.g. maximize it)
68 (commented on others PR)
Would it be better if you leave all these changes to the default one? Because I think it is the conventional way to express as top, right, bottom, left.
69 (commented on others PR)
Similarly for this, I think there is no reason to change their positions?
70 (commented on others PR)
Good that you make it consistent with the others
71 (commented on others PR)
Is there supposed to be a use for this? I can't find any place that uses this matcher object
72 (commented on others PR)
Maybe you will like to include an example usage as well
73 (commented on others PR)
Will you like to move this to the UpdateCommand parent class instead so that it is not duplicated in UpdateProceedCommand class?
74 (commented on others PR)
If you are moving the MESSAGE_NULL_STATUS to UpdateCommand class, then perhaps this should be moved as well for consistency
75 (commented on others PR)
Same as the comment in UpdateCancelCommand
76 (commented on others PR)
It seems weird to me that next() for Completion returns a Completion?
77 (commented on others PR)
Ohh, I see
78 (commented on others PR)
Would it be better if the .next() method is never called for Completion? But I do understand that it has to implement the method in this scenario. So I guess its fine.
But perhaps one other suggestion is to show the user that it is already completed or something if user pass in a command to update a completed property to the next stage?
79 (commented on others PR)
Yeapp!!
80 (commented on others PR)
Didn't realize that the update command is called as such update 1 proceed/, without anything behind the prefixes. So they are not really prefixes in this case, so maybe the forward slashes are not intuitive for the user and should be removed. Sorry!!
An alternative suggestion may be to change the command format to update INDEX s/STATUS?
E.g. update 1 s/NEW, update 1 s/proceed, update 1 s/cancel
In this case, you can even make use of the ArgumentTokenizer and ArgumentMultiMap classes to parse the inputs.
Will this be better?
81 (commented on others PR)
Maybe change Undoes to Undos?
82 (commented on others PR)
Undid?
83 (commented on others PR)
Undos?
84 (commented on others PR)
Undos?
85 (commented on others PR)
Correct me if I am wrong but do you have to set the previousAppointmentLists of previousAppointmentBook as well? So that the user can call undo two times in a row?
86 (commented on others PR)
Same as the comment for AppointmentBook
87 (commented on others PR)
Can this method be shifted to PocketEstateParser instead? So that the regex and parsing are not duplicated.
Let me know if it is not possible because it will affect the implementation or if there are any other reasons
88 (commented on others PR)
Actually, the main question is just whether the user can call undo two times in a row now?
89 (commented on others PR)
Ohh,that's good! Then we can merge this.
90 (commented on others PR)
I think we shouldn't add this kind of setting files to the team repo. Can you leave this file out or put it in the .gitignore?
91 (commented on others PR)
I don't think we should change this file too
92 (commented on others PR)
I think we should be consistent with the add property command and use [t/TYPE] to indicate that the filter is for property type
93 (commented on others PR)
Do you mean accepted here?
94 (commented on others PR)
Can reuse the PREFIX_TYPE defined earlier in the file instead of defining a duplicate one
95 (commented on others PR)
Is there a reason for defining a separate method to get properties with clients? Will it be better to just include JURONG in the getTypicalProperties method?
96 (commented on others PR)
What does julLogger stand for? Will it be better to use a more descriptive name?
97 (commented on others PR)
I think we should be consistent and use t/PROPERTY_TYPE here
98 (commented on others PR)
Need to remove appointments here
99 (commented on others PR)
This should be appointments instead
100 (commented on others PR)
I think it will be better if the ... are after the square brackets.
E.g. find property [KEYWORD] [OPTION]...
101 (commented on others PR)
Is the diagram changed or updated? If not, I think we shouldn't change the .puml file too
102 (commented on others PR)
Should it be EditAppointmentDescriptor instead?
103 (commented on others PR)
Just wondering if the \n should be taken out because the user can never enter a \n in our app right? Hitting the enter button will result in executing the command alr. 🤔
104 (commented on others PR)
Do use the constructor with both property book and appointment book as the other constructors should be removed asap
105 (commented on others PR)
Can you change this file back to the original version or leave this file out?
106 (commented on others PR)
What is this commented out testcase for?
107 (commented on others PR)
Similarly for this
108 (commented on others PR)
Perhaps use PropertyBuilder here?
109 (commented on others PR)
I am fine with this but perhaps use static variables for this? Something like INVALID_COMMAND_ADD?
110 (commented on others PR)
Food for thought: how about finding client and the other extra stuff (finding by postalcode, etc) yuchen is adding? Or do we only prompt appointment and property because they are more important?
111 (commented on others PR)
Ohh i meant the "add", "find", "clear", etc
112 (commented on others PR)
So that they are not magic strings
113 (commented on others PR)
ok
114 (commented on others PR)
just a small nitpick, but personally would prefer the options to be grouped in this way:
[KEYWORD]... [pl/UPPER_PRICE_LIMIT] [pm/LOWER_PRICE_LIMIT] [t/TYPE] [p/POSTAL_CODE] [a/ADDRESS] [r/REMARKS] [tags/TAGS_SEPARATED_BY_COMMA] to make it consistent with the rest of the commands
115 (commented on others PR)
I agree with david that you should probably try to use ArgumentTokenizer here. This function has to be modularized one way or another because it is way too long and not reader-friendly now
116 (commented on others PR)
Should this be matches the remark given instead?
117 (commented on others PR)
Perhaps this can be clearer by saying ... contains all of the tags given?
Side note: should this be changed to contains any of the tags given instead? Since the user might want to use a few tags to search for properties with any of them.
118 (commented on others PR)
I dont think its a good idea to duplicate the code from FindPropertyCommand#parse to here again. Given that this is a test class, is it possible to manually create the Predicate/PredicateList in each of the test itself instead?
119 (commented on others PR)
Sorry, this way instead because address should be before postalcode:
[KEYWORD]... [pl/UPPER_PRICE_LIMIT] [pm/LOWER_PRICE_LIMIT] [t/PROPERTY_TYPE] [a/ADDRESS] [p/POSTAL_CODE] [r/REMARKS] [tags/TAGS_SEPARATED_BY_COMMA] to make it consistent with the rest of the commands
120 (commented on others PR)
Will adding n/ for name be a solution? Since we are adding prefixes for the rest.
121 (commented on others PR)
Just wondering if you separate out this 3 formats of update in the command summary, then should you separate them in the Command section above too? Its better to be consistent so if you want to separate out to 3 formats, then both sides should be separated. If not, both sides should be 1 format only.
122 (commented on others PR)
Actually will it be better if you have only 1 format, update INDEX u/OPTION, then you specify what the options are? Similar to how find is structured?
Not really sure whats the best way to present this...
123 (commented on others PR)
Should you also add a bit more information on what each of the status represents, and calling proceed on one will lead to which one?
124 (commented on others PR)
Maybe state what the amount means also?
125 (commented on others PR)
Would prefer a nested table to explain what option, sales agreement and completion mean here. But ignore me if you don't think its better
126 (commented on others PR)
There will be error parsing the html tags here. Try following what i did for the find property command below if you can. If not I will fix it after this is merged ba
127 (commented on others PR)
omg im so sorry i meant like a nested list like that
- ...
- ...
cuz a table would be kind of out of place right?
128 (commented on others PR)
Should this be UserPrefs instead?
129 (commented on own PR)
withAppointment takes in an actual Appointment object. So if an example is given, it will be quite verbose.
E.g. AppointmentBook ab = new AppointmentBookBuilder().withAppointment(new Appointment(new Name("Meet Alex"), new Remark("remark"), new Date(LocalDate.parse("2021-01-01")), new Time(LocalTime.parse("20:00:00"))).build();
So I don't think it is necessary to put. Let me know if yall think we should include it.
130 (commented on own PR)
Ohh right good point. Shall change it. Thanks.
131 (commented on own PR)
Thanks, merged and updated this branch
132 (commented on own PR)
ok!
133 (commented on own PR)
ohh ok!
134 (commented on own PR)
Will update this
135 (commented on own PR)
@dvdweien to update this section
136 (commented on own PR)
@dvdweien to update this section too
137 (commented on own PR)
The format is supposed to be t/hdb for example
138 (commented on own PR)
@w-yuchen to update this section
139 (commented on own PR)
ohh, thanks for catching this
140 (commented on own PR)
Shall update this
141 (commented on own PR)
I think we should probably separate source code and test code
142 (commented on own PR)
Same as above
143 (commented on own PR)
Same as above
144 (commented on own PR)
Same as above
145 (commented on own PR)
Oops, forgot to remove
146 (commented on own PR)
will remove them
147 (other comment)
Update target user profile and value proposition.
Add glossary.
148 (other comment)
Add user stories.
149 (other comment)
should I close this pull request?
No, this is for the tutorial only.
150 (other comment)
Do remember to update the command summary for these commands at the bottom of the user guide page as well
151 (other comment)
Only property types "hdb", "condo" and "landed" and all forms of their capitalization are allowed for the PropertyType attribute of a property
152 (other comment)
I think that we originally discussed and decided that the asking price should be an optional "client asking price", so I had put it under client info. We can discuss more about this in the next meeting to see if we want to change it to be under property directly.
153 (other comment)
Do you mean like this? Is this better?
154 (other comment)
i think can lose the underline, maybe the bold isn't needed oso. I was just confused why every date was red
Then wont it be the same as the original alr? The main idea was to place some emphasis on the dates so that the user can see his upcoming deadlines/appointments more clearly
155 (other comment)
@candyhy what do you think of this 🤔
156 (other comment)
Updated image:
157 (other comment)
Storage interface should extend PropertyBookStorage, AppointmentBookStorage and UserPrefsStorage too
158 (other comment)
This shouldn't be execute(undo) right
I think should enclose the parameter in quotes cuz its supposed to be a string
should be dotted line for returning
This is a constructor call, so the label shouldn't be 600000 I think. Either leave it blank or change it to a call to create a new Option object
should be dotted line for returning
should be dotted line for returning
missing returning dotted line (if everywhere else has a returning dotted line, then u should probably include one here too)
159 (other comment)
Your diagram:
My diagram:
For this, I do agree that the 3 child classes should have a composition relationship with Offer, and I will update my diagram. But do you think there should be a dependency arrow from Status to Offer as well?
160 (other comment)
I don't think there should be a dependency arrow from Status to Offer as Status doesn't actually have any knowledge of Offer, Offer is only referenced in the classes that implement Status
Ohh, because I thought Status has a method returning an Offer object. Hmm, not really sure whether to include this dependency arrow...
161 (other comment)
I don't think there should be a dependency arrow from Status to Offer as Status doesn't actually have any knowledge of Offer, Offer is only referenced in the classes that implement Status
Ohh, because I thought
Statushas a method returning anOfferobject. Hmm, not really sure whether to include this dependency arrow...
Oh yeah! I forgot about that, that method isn't currently being used now should i remove it? If it shouldn't be removed then i will add the dependency arrow
Ohh, its not being used? Then ya please remove and I will update my diagram. Thanks!
@vevek (113 comments)1 (commented on others PR)
Agreed. Full name for everyone would be great.
2 (commented on others PR)
Agreed
3 (commented on others PR)
@Eriksen2411 Yes 😃
4 (commented on others PR)
In that case would it be
In charge of: Deliverables and deadlines
vs
Role: Deliverables and deadlines
vs
Role: In charge of Deliverables and Deadlines
5 (commented on others PR)
I think there should be a space between // and Set.
6 (commented on others PR)
I think there should be a space between // and Maximise.
7 (commented on others PR)
Nice touch.
8 (commented on others PR)
Add space below.
9 (commented on others PR)
Yup, I'll add an issue!
10 (commented on others PR)
Nice
11 (commented on others PR)
colab_icon_32 would be easier to differentiate. 32 being an example size.
12 (commented on others PR)
Perhaps all colour constants can have a prefix. COLOUR_PRIMARY_LIGHT and COLOUR_ACCENT.
13 (commented on others PR)
COLOUR_CELL would be better. "Cell" is unclear.
14 (commented on others PR)
What's the reason why it is NaN?
15 (commented on others PR)
Nice!
16 (commented on others PR)
Any reason for this specific resolution? Perhaps a generic 1280x720 or 1920x1080 would be consistent among different computers.
17 (commented on others PR)
line space between if statement and previous line
18 (commented on others PR)
line space
19 (commented on others PR)
indentation. && should be aligned to ||.
20 (commented on others PR)
Do add the types in the array list as well. It's failing the checks.
"new" has been duplicated twice.
21 (commented on others PR)
Here
22 (commented on others PR)
A list of Persons -> Tasks instead.
23 (commented on others PR)
This one can use requireNonNull(), but no big deal.
24 (commented on others PR)
This one can use requireNonNull(), but no big deal.
25 (commented on others PR)
This one can use requireNonNull(), but no big deal.
26 (commented on others PR)
I love how your comments are so detailed btw! 😃
27 (commented on others PR)
Should it be target.isSameProject(edited) && contains(editedProject) without the ! in front of target.isSameProject(edited)?
28 (commented on others PR)
Nothing implemented here
29 (commented on others PR)
Should there be a requireNonNull(project) here?
30 (commented on others PR)
Should there be a requireNonNull(key) here?
31 (commented on others PR)
Need to implement. Why return null?
32 (commented on others PR)
Should the predicate being imported be PROJECTS instead?
33 (commented on others PR)
Here too.
34 (commented on others PR)
Personally I feel that if we have to reference something from the Command class, then it might be better to put this message within the Command class rather than Messages. What do you think?
35 (commented on others PR)
I like this change, but maybe wanna add the requireNonNull(projectToEdit); before this line.
36 (commented on others PR)
Not a big deal but I think having the comma makes sense.
37 (commented on others PR)
Why not have 2 constructors. The one with 3 parameters shall require non null for all 3 fields. So that when it is used externally, it is used correctly. The one with 2 parameters shall require non null for 2 fields.
38 (commented on others PR)
This will then need to be updated.
39 (commented on others PR)
Lets standardise the way this message_usage String is formatted in the future 😃
40 (commented on others PR)
@samuelfangjw Referring to standardising it over all the command classes. Not too important for now. I wanted to neaten it for the other command classes.
41 (commented on others PR)
Was referring to this part, that refers to the COMMAND_WORD. Not a big deal for now since command word will most likely be unchanged.
42 (commented on others PR)
@samuelfangjw Added a new comment to the correct line for this.
43 (commented on others PR)
Sure!
44 (commented on others PR)
Add extra line here
45 (commented on others PR)
Extra line here.
46 (commented on others PR)
Add extra line here.
47 (commented on others PR)
Just a minor suggestion. I think convertedProjectName would be clearer here. Since there are many variables starting with "project" and "projectName"
48 (commented on others PR)
Is there a reason why you do this once here, and then assertDoesNotThrow for the same thing below?
49 (commented on others PR)
Looks repeated as the one below.
50 (commented on others PR)
Looks repeated as the one here.
51 (commented on others PR)
Can the Set(i,deadline) method be used instead. This way the list would not get reordered unnecessarily.
52 (commented on others PR)
Can the Set(i,deadline) method be used instead. This way the list would not get reordered unnecessarily.
53 (commented on others PR)
Do you wanna make this change to EventList too?
54 (commented on others PR)
Do you wanna simplify "deadline.getIsDone() ? "✔" : """ with a method in Deadline? Or even from toString?
55 (commented on others PR)
Do you wanna simplify "todo.getIsDone() ? "✔" : """ with a method in Todo? Or even from toString?
56 (commented on others PR)
I think it would be better if DP can be labelled better. Like DP_COLOR_NO_TRANSPARENCY etc
57 (commented on others PR)
Same as above
58 (commented on others PR)
Got it, then DP_1_ELEVATION would be good
59 (commented on others PR)
Sounds good to me!
60 (commented on others PR)
I think it is better to have it in the previous form, so that the ParseException e's message can be shown to the user as well.
61 (commented on others PR)
Although the new design does simplify things.
62 (commented on others PR)
The method header name here is wrong. For other methods, your method header names also seem irrelevant to the what the test actually does.
63 (commented on others PR)
Wrong method header.
64 (commented on others PR)
Header names here are fine
65 (commented on others PR)
Oh okay. In that case, nice catch 😃
66 (commented on others PR)
Good idea!
67 (commented on others PR)
So for now there is not mechanism to tick the todo off in via the GUI right? It'll just update the GUI accordingly?
68 (commented on others PR)
Was id left out intentionally?
69 (commented on others PR)
Is the ID here intentionally left out?
70 (commented on others PR)
id here too
71 (commented on others PR)
Reading this, it looks like ID should be checked too. Hmm
72 (commented on others PR)
here too.
73 (commented on others PR)
Maybe the UiCommand can be specified to be ViewProjectUiCommand since that is the current context?
74 (commented on others PR)
and here.
75 (commented on others PR)
Looks better man!
76 (commented on others PR)
Is it overridden instead of overwritten?
77 (commented on others PR)
Looks better man!
78 (commented on others PR)
Got it man, thanks
79 (commented on others PR)
Perhaps can add requireNonNull for dateOfEvent
80 (commented on others PR)
requireNonNull
81 (commented on others PR)
requireNonNull
82 (commented on others PR)
requireNonNull
83 (commented on others PR)
Looks like id isn't being used at all.
84 (commented on others PR)
I remember the implementation here was changed, or is this correct?
85 (commented on others PR)
Perhaps can requireNonNull here for Event just to be thorough
86 (commented on others PR)
Wanna change the string text for this and deadlines to a constant declared at the top for easy access?
87 (commented on others PR)
In reference to the previous PR haha
88 (commented on others PR)
I see. That does make sense and simplifies a lot of things!
89 (commented on others PR)
"events list" can be changed to "EventList"
90 (commented on others PR)
issues & ececutes change to "executes"
91 (commented on others PR)
It checks Event provided is valid or not -> It checks if Event provided is valid or not
92 (commented on others PR)
"an exception will be thrown, Ui will" change to "an exception will be thrown and Ui will"
93 (commented on others PR)
It check whether -> It checks whether
94 (commented on others PR)
and Event provided is duplicated or not -> and if Event provided is duplicated.
95 (commented on others PR)
I kind of don't understand what is being said here.
96 (commented on others PR)
works -> work
97 (commented on others PR)
works -> works.
98 (commented on others PR)
remove the word "issues".
-> The user executes the command
99 (commented on others PR)
not work with the immutable -> not work with an immutable
100 (commented on others PR)
Maybe this line can change INVALID_REPEATABLE_DATE -> INVALID_EVENT_DATE.
can't merge with deadline one because of the different prefix.
101 (commented on others PR)
Nice explanation man
102 (commented on others PR)
Does it need to catch DateConversionException too, given that it is thrown in checkDateIsNotNegative? Or is DateConversionException a subclass of DateTimeParseException?
103 (commented on others PR)
I checked and it doesn't appear to be a subclass of DateTimeParseException
104 (commented on others PR)
Hmm, because they throw with different messages, perhaps can leave it as it is?
105 (commented on others PR)
The syntax changed to "addEto PROJECT_INDEX d/DESCRIPTION on/DATE at/TIME w/Y"
106 (commented on others PR)
This one I feel it would be better to have 2 constructors. 1 that has only 1 parameter for ColabFolder and sets CommandResult to null be default. And another constructor that has 2 parameters such that both parameters would have requireNonNull.
Not a very big deal because the Null in parameter is only used in ColabFolderHistory
CommandResult.
107 (commented on others PR)
Should just be name here. Its showing the entire package currently
108 (commented on others PR)
Was day here intentionally left as 4 chars? as it has been shortened to 3 chars above.
109 (commented on others PR)
Is it supposed to be > "Repeatable" > here
110 (commented on others PR)
Is this method still used?
111 (commented on others PR)
If so, it could reused in line 49.
112 (commented on others PR)
👍
113 (commented on others PR)
Ok. Not a big deal since we only have 1 type of repeatable
114 (commented on own PR)
Oh nice catch. thanks @Eriksen2411 !
115 (commented on own PR)
np!
116 (commented on own PR)
np!
117 (commented on own PR)
Good catch. Added it. Thanks!
118 (commented on own PR)
Yup! I took from address field because that allows for long and varied sentences. I think the one from project name allows only for 2 words
119 (commented on own PR)
Thanks!
120 (commented on own PR)
Thank you. I will merge the changes and request review again 😃
121 (commented on own PR)
Will resolve this at a later date. Placed in issues. 😃
122 (commented on own PR)
Good idea!
123 (commented on own PR)
Thanks!
124 (commented on own PR)
Nice thanks!
125 (commented on own PR)
Nice. fixed!
126 (commented on own PR)
thanks!
127 (commented on own PR)
thanks!
128 (commented on own PR)
thanks!
129 (other comment)
LGTM
130 (other comment)
Dimensions have been updated.
131 (other comment)
@samuelfangjw thanks. I have updated the title and the description.
132 (other comment)
Pull Request was closed due to deletion of branch. No merging was done.
133 (other comment)
@samuelfangjw Looks great! Please add the changes you have added to features to the table of contents.
134 (other comment)
Nice work! LGTM!
135 (other comment)
LGTM.
136 (other comment)
Nice work. LGTM!
137 (other comment)
@samuelfangjw the images that show the features in detail. It can be seen in the pages further below in the user guide.
138 (other comment)
@samuelfangjw Good catch 😂
139 (other comment)
@samuelfangjw I think you've found the one 😂
140 (other comment)
Are you able bring back the v1.1 milestone?
141 (other comment)
@samuelfangjw Looking forward to it hahaha!
142 (other comment)
@samuelfangjw Nice thanks. I'll get on it soon!
143 (other comment)
@samuelfangjw Good idea!
144 (other comment)
Closing as Tutorial PR irrelevant to project.
145 (other comment)
Thanks! @samuelfangjw
146 (other comment)
Nice. LGTM man!
147 (other comment)
Might need to check the things brought up in the comments. Accidentally approved and left out this comment.
148 (other comment)
All the models, storage and tests have been updated. PR is ready for review. Thanks!
149 (other comment)
Tests aren't sufficient, but we'll ignore that for now so that the rest can proceed. I'll add more tests over time.
150 (other comment)
Done up all the necessary classes for AddTodoCommand and related classes. Some changes and additional checks were added/made to AddEventCommand and related classes. I have yet to do up tests for AddTodoCommand. I will do AddDeadLineCommand after this, and then will add the tests for Todo and Deadline at the same time. Thanks!
151 (other comment)
Done up all the necessary changes for AddDeadlineCommand and related classes. Some changes were made to AddTodoCommand and AddEventCommand. I will work on deleteE/T/D and then do the tests for all. Thanks!
152 (other comment)
Ready for review. Tests will be added at a later date after deleteEvent & deleteDeadline are done.
153 (other comment)
Ready for review. Will add tests soon after merge.
154 (other comment)
Ready for review. Will add tests soon after merge.
155 (other comment)
Ready for review.
156 (other comment)
Ready for review.
157 (other comment)
Done up the tests for AddTodoCommand and it's related tests.
158 (other comment)
Ready for review! Thanks!
159 (other comment)
Made relevant changes and fixed some issues. Fixed a minor issue with a test for DeleteContactFromCommandTest. Ready for review. Thanks!
160 (other comment)
Ready for review! Thanks!
161 (other comment)
Ready for review, thanks!
@kouyk (107 comments)1 (commented on others PR)
This might sound like a bit of nitpicking, but then if I don't other teams might, the "adds" in this sentence can be confusing, perhaps we can use something like append/include/insert? Same for the things below.
2 (commented on others PR)
I think this is the same issue as what you have raised about separation of the add/delete of dog/owner, in this case shall we just keep things simple and simply call it "missing required information"? To maintain clarify we can put a note at the bottom saying what field are required for dogs and owners. Doing it this way reduces clutter since we can combine more things together, makes any future edits less likely to miss out any detail.
3 (commented on others PR)
the image name needs to be wei-yutong.png to match your github username, you should be able to rename it easily thru gui or by using the git mv command
4 (commented on others PR)
5 (commented on others PR)
the blank lines prevent the table from appearing correctly
6 (commented on others PR)
Remove this line perhaps?
7 (commented on others PR)
Maybe we can include dogs and programs in here too?
8 (commented on others PR)
I feel that this line a bit weird? It does make sense though if we have the feature to take note if someone has paid for the upcoming program.
9 (commented on others PR)
There's the black circle symbol, is this intended?
10 (commented on others PR)
For headings I think it is fine to leave out the bold if we are going to use headings. It is also necessary to leave a space in between the # and the word after for it to take effect.
11 (commented on others PR)
As in the hash-tag is a hash-tag not used as heading? Because throughout the document it seems like they are intended to be headings, if you preview the rendered markdown.
12 (commented on others PR)
Yea, you can refer to our submitted user guide.
Oh but if we still want to keep the dot right, would it be better to use the markdown representation so it is rendered nicely?
13 (commented on others PR)
I closed it because idk how to rename the commit message xD.
You can try git commit --amend -m "Your new commit message".
14 (commented on others PR)
this might need to be a part of the addressbook instead, given that storage will likely modify it after reading back the saved file, and especially since in the tests there will be different addressbooks created, but a simple equal will fail since there is no way to sync up the id numbers
15 (commented on others PR)
isn't it just otherOwner.getID() == getID()? and I think we can do away with this check since it is reasonable enough that 2 owners with all details that are the same point to the same person, and some tests also uses this method to compare between owners.
16 (commented on others PR)
maybe do some basic checks at this point for the owner keyword? the tests can also be updated this way and at least the syntax will be updated.
17 (commented on others PR)
This is a really strange change, might be due to the problematic git history.
18 (commented on others PR)
This is not a bug, if you look carefully at the condition that triggers the exception, it is either when some compulsory arguments are missing or that there is some additional things in between the command keywords and the arguments. In this case, saying the unknown argument might be applicable, but only for the latter scenario. The more useful thing choice is to display help for the particular command or even subcommand like add owner will display the specifics are adding an owner.
19 (commented on others PR)
Try not to introduce additional line breaks that do not have much meaning.
20 (commented on others PR)
I like that you have added in the javadocs, however, this is to be kept private as it is an internal helper method that should not be exposed to any other users. Perhaps you made it public in order to write test code for it, but I think it is better to refrain from that since it is the public API that we are testing out, the test code should not care about the actual implementation so long as it does what it promises. Else we will fall into this never ending issue of making all methods of every class public. I could have inlined these two lines into the switch case of the main parse method, but for SLAP I created the helper functions.
21 (commented on others PR)
As commented above, this testing should not happen anymore, but should instead be tested through the parse method. Also, try to make use of the constants already defined to come up with the command instead of the magic literals.
22 (commented on others PR)
The brackets of the the lambda arguments should not be split into 2 lines, especially not when they are empty.
23 (commented on others PR)
checkstyle has passed for these code or else it won't have been possible to merge them, so I think it might be a problem with your IDE configuration.
24 (commented on others PR)
Yes, you can take a look at the rest of the code base and see how it is done for the others. Especially for helper methods that are more concerned with internal implementation, they could be very dynamic and change every time.
25 (commented on others PR)
is this going to match all kinds of date formats or just our specified one?
26 (commented on others PR)
I think we came to a conclusion last week that this field is to be storing an ID of the owner.
27 (commented on others PR)
does it mean dogs can have the entire spectrum of sexuality now?
28 (commented on others PR)
Nope this is perfect. But just need to make sure that the LocalDate parser is able to handle this variety. Maybe add a comment above it to indicate what it is looking out for? It will help make it more readable.
29 (commented on others PR)
Yup, the idea here is to take in the ID and verify with the backend that the owner does exist for this ID to be considered valid. But you can just put some placeholder functions now when it comes to the adding part.
30 (commented on others PR)
Hmm, then do we want a validation regex just like the date?
31 (commented on others PR)
a bit of nitpick but got extra lines
32 (commented on others PR)
perhaps there's a more succinct way to express this, but i think it's fine for now
33 (commented on others PR)
I was wondering if it is better to store the date of birth and calculate the age from there.
34 (commented on others PR)
Oops
35 (commented on others PR)
I'm not so sure if we want interface templates instead of abstract base class, since interfaces only define methods, no common data like name or tag can be made common, the other thing is when it comes to writing functions like find it might be difficult to avoid boilerplate code.
36 (commented on others PR)
where the spectrum hahaha
37 (commented on others PR)
Maybe we can avoid the dilemma just by calling it Sex, since gender is what you identify with, sex is biological, easier to just have an other instead.
38 (commented on others PR)
Is it better to store it as LocalDate instead? this will simplify a lot of things especially for the getAge method. And it will be easier for us to manipulate into any other format elsewhere, say the UI and json.
39 (commented on others PR)
Is it cleaner if we just parse using LocalDate right from the start? Something like LocalDate localDate = LocalDate.parse(dob, DateTimeFormatter.ofPattern("d-M-yyyy"));
40 (commented on others PR)
Is the indentation here supposed to be 8 spaces? Can consider updating your IDE settings to automatically indent by 8 spaces.
41 (commented on others PR)
package private?
42 (commented on others PR)
Tbh I'm quite keen to remove the use of INDEX__, because we have switched to referencing by ID and not by the visible index number. For this method it is fine of course, but there is a need to probably remove Index and create an ID class in its place, but that's probably another issue to be created.
43 (commented on others PR)
Not to mention the convoluted construction and usage of the Index class doesn't seem to help.
44 (commented on others PR)
I only have myself to blame for this, maybe at least we can extract it into some form of a helper method in the util class? it isn't very straightforward that we are deleting the first dog since we are still using getTypicalAddressBook just from a different class.
45 (commented on others PR)
This is referring to the ModelStub btw
46 (commented on others PR)
As in because previously there was only one CommandTest so given ModelStub's nature it made sense to just have it as a private class of the Command, but going forward we probably want to abstract out a bit of these test code as well. The ModelStub should become a package private shared by all the CommandTests, it will be good to combine the tests under AddCommandTest.
47 (commented on others PR)
do you want to change it to entity-level
48 (commented on others PR)
int can never be null, that's why it doesn't have the check. and perhaps you can update the javadoc to refer to Entity while you're at it?
49 (commented on others PR)
can just delete directly since all usage already changed
50 (commented on others PR)
hmm why expose the this actually?
51 (commented on others PR)
I think can revert this portion of the commit and preserve the one above.
52 (commented on others PR)
I don't quite understand the reason behind this change. There's another one below as well.
53 (commented on others PR)
This particular overload is to make it possible to use the same ID across restarts using the one stored in the file. The check for ID is not redundant since it is possible that someone modified the file to make 2 entities have same ID, then they will come and file a bug.
54 (commented on others PR)
same as what was mentioned above.
55 (commented on others PR)
this is very dangerous, it exposes the internalList directly to modifications beyond this class, is there a reason for this?
56 (commented on others PR)
maybe use a valid ID number? I think I have settled on positive integers.
57 (commented on others PR)
okay I think i get the rationale for the returning the internalList directly, but it is alright to use the unmodifiable version as many other tests does the same. Also I think if this is targeted at owners but will not test dogs, it is a good idea to filter using instanceof as well.
58 (commented on others PR)
same the other one
59 (commented on others PR)
Okay I understand this portion now, it might seem fine to do this for now, but the issue is that this codebase isn't very small, having equivalent api will confuse others that are not so familiar with this portion, and any direct modification is now possible since Java passes by reference, it will be difficult to track down bugs if someone modifies it and violates the assumptions we have about unique entities etc.
60 (commented on others PR)
this can be another test to remove an invalid ID equivalent to the null test above.
61 (commented on others PR)
this indentation doesn't make sense, since it is a continuation of the bracket of the previous line, the && on this line is not at the same level as the || on the previous line.
62 (commented on others PR)
Could use some updated variable names.
63 (commented on others PR)
This also can be renamed.
64 (commented on others PR)
Here too!
65 (commented on others PR)
Naming for this as well.
66 (commented on others PR)
extra line breaks!
67 (commented on others PR)
is it better to use the hasEntity method to check if the ID exists and throw an exception if it doesn't. then we can assume that getFilteredEntityList will return something that definitely contains the owner, then we retrieve it for real this time and check if it is indeed an owner object instead of any other entities. It will be better to use the setEntity method to change the target owner by creating a new copy with the up to date details.
68 (commented on others PR)
arrayset might be better?
69 (commented on others PR)
as mentioned in the AddDogCommand portion, it will not necessary to directly modify the Entity objects since all attributes are constant throughout the lifetime of the object. This is to align to the original AB3 codebase whereby the edit command also modifies by creating an updated instance of Person before asking the model to set it as the new one.
70 (commented on others PR)
there shouldn't be a need to do this as well.
71 (commented on others PR)
Hmm then maybe HashSet will do also, btw can just leave it without the specific type of implementation, i.e. List instead of ArrayList, Set instead of Hashset, there's a discussion on the forum on this.
72 (commented on others PR)
and a set makes more sense for our case, since we don't really need an order to them, it is more ideal in the sense, but why not get it right at the start and not worry later.
73 (commented on others PR)
Another thing of note is that we have to ensure that the check that the entity we have is an instance of Owner first, or else we might be downcasting illegally, it would be a good opportunity to throw an exception along the lines of id doesn't refer to owner.
74 (commented on others PR)
Will it be better if we keep naming a little more consistent here? Since elsewhere in the I have already used something like idEntityPair, it will be confusing to see idEntity here since it can be ambiguous. I think a better alternative would be to simply name it idNumber or simply just id.
75 (commented on others PR)
There's an extra line break here. Other than that, another naming thing again, this applies to other areas as well, is it better if we use either id or ID in the naming and don't mix the casing? It helps to make things consistent as well.
76 (commented on others PR)
Naming is especially confusing for this part, since idEntity supposedly refers to a pair already.
77 (commented on others PR)
Refrain from commenting like that, a better practice when using git is to simply delete all these lines that you don't need or want to disable, commit this set of changes as an individual commit. If you intend to fix it later, maybe leave a todo around the original area. This way even if we don't implement it there won't be a need to clean up the code much. But if you do intend to restore this portion, it will be simply a matter of finding the commit that removed the lines and reverting it, creating an additional commit that essentially negates the removal yet retaining full history.
78 (commented on others PR)
this makes Owner mutable.
79 (commented on others PR)
and also this.
80 (commented on others PR)
Maybe can declare an integer on top first but don't initialise it? then in the try part can use the result of parseInt such that it can be directly returned below.
81 (commented on others PR)
indent one more layer.
82 (commented on others PR)
This is not something that is meant for an assertion, since it is one of the expected possible errors that we need to handle. Assertions are for verifying assumption that should not be broken and if they are indeed broken, the program is unable to handle and we need to investigate further. I suggest that this be removed.
83 (commented on others PR)
this needs to be removed
84 (commented on others PR)
this instance here is redundant as well, since it will cause the if below to trip otherwise.
85 (commented on others PR)
is it better to separate into 2 conditions so the error message can be a lot more precise?
86 (commented on others PR)
instead of calling getEntity multiple times, it seems better if the result is saved first and reused later, the code will become more readable this way. and i think it is fine to separate the 2 checks here as well, since for a lot of other commands it fails at the first incorrect one.
87 (commented on others PR)
this comment does not explain the invalidity well, since session but not obvious, thus it is better to explain it as an illegal date format
88 (commented on others PR)
does the java coding style require that the indentation be aligned this way? this seems more like a c/c++ styling
89 (commented on others PR)
I know this is a copy and paste from the tests for owner, but please drop the unfiltered part, if you wish you can drop them from the owner side as well. You probably don't understand the original behaviour of AB3, but it originally referenced to every entry by their index in the displayed list, thus filtering makes a difference to whether or not one can reference to a particular Person. We have since switched to using ID and whether or not the target entity to be edited is visible or not no longer matters. If you haven't noticed, there is no longer a filteredlist complement test as I've deleted them, but to prevent too many changes in one PR I refrained from doing the small renames.
90 (commented on others PR)
How about doing this test for the EditEntityDescriptor instead? While testing here may or may not be redundant, it helps more to test the base class as well in case the bug actually lies inside there and the child classes are just a distraction from the real problem. This applies to tags as well.
91 (commented on others PR)
I don't understand the rationale behind this change
92 (commented on others PR)
For typical dogs, I have inserted an owner so as to make all dogs have a valid owner. And that the ID of the owner is 1, therefore all dog IDs are offset by 1. The fix here should not be with the dog ID, but rather it should be the input text. You might feel that both are equivalent, but fixing it like the current way is convoluted and nobody can understand why the input is 1 yet the ID of the first dog does not match.
93 (commented on others PR)
it is ID now, please help to rename for all the various tests as well.
94 (commented on others PR)
could use consistent format like above.
95 (commented on others PR)
comment needs updating.
96 (commented on others PR)
in this case all fields should be repeated including the owner id
97 (commented on others PR)
it will be good to test against EditCommandParser as well. I know it is an abstract class, but it is possible to create a simple implementation and test against that, especially for things like tags which there is a protected method that handles it for all classes. That way things like preamble etc only need to be tested once and not repeated since having repeated test cases on the same thing does not help with code coverage or prevent bugs but only increase the execution time of tests.
98 (commented on others PR)
It will be good to adhere to the DRY principle and apply some OOP like in the main codebase. That way setName and setTags can all be simplified. It helps that EditEntityDescriptor is already in place so there isn't as much tweaking to do. This was also one of the reason I rewrote the Edit command implementation to ensure minimal repetition, avoiding potential points of failure when copying blindly and not keeping necessary parts updated.
99 (commented on others PR)
Similar to the builders as well, using OOP to adhere to DRY principle is better since we have no test code for test code, else this will result in some infinite recursion.
100 (commented on others PR)
originally this file worked together with only one typical addressbook, but now there is 3 copies on top of the fact that there is no longer ID, I think it will be better to define these constants directly within each addressbook to avoid confusion. Each of those addressbooks require better naming as well as they are not descriptive at all and there is nothing typical about them. To make it more typical, perhaps it is good to just combine 3 of those into a TypicalEntities class instead. Something like getOwnersOnlyAddressBook and getSingleOwnerMultipleDogsAddressBook will help make things clear.
101 (commented on others PR)
can there be examples here as well?
102 (commented on others PR)
this should be pawbook?
103 (commented on others PR)
Still got addressbook here
104 (commented on others PR)
do you want to also rename the json files?
105 (commented on others PR)
the method names too!
106 (commented on others PR)
probably need separate this rename as part of another commit so as to track as a rename instead of creation of new file. There's several references that needs to be renamed as well
107 (commented on others PR)
this line is copy pasted from somewhere?
108 (other comment)
You might want to go to Settings > Editor > General > On save, and enable Ensure every saved file ends with a line break, can prevent future CI from failing.
109 (other comment)
that EOL thing is really quite annoying, can refer to anli's pull request where I detailed the instructions to make the ide add the extra line at the end of every file
110 (other comment)
do you want to split this PR into 2 though? like it is easier for someone else to just merge your README updates separately, plus adding the mockup image first also allow everyone to get a copy from master faster
111 (other comment)
Quick question, do you intend to do the formatting now or just leaving it in this state? Because as you are the first to completely rewrite the user guide, this will set the precedence for others.
112 (other comment)
Also, you might want to create an issue and assign it to yourself for this.
113 (other comment)
You need to rename the image itself too!
114 (other comment)
Duplicate of #51
115 (other comment)
You might want to install the checkstyle plugin on intellij and run it locally before committing. Another way is to run them using the command line via gradle like what the course material mentioned, which I will not repeat here. There are two advantages to this, firstly you get feedback faster, since it is much quicker to run locally than for the CI to return its results, next several of us are watching this repo, each pull request and separate commits pushed to a PR will generate notifications/email for everyone subscribed, reducing unnecessary notifications will be helpful for everyone.
Another thing I've noticed is that intellij files are seeping in, i.e. src/.idea, by right .gitignore is configured to not add these files, you might want to check your setup to ensure that the excluded files are indeed excluded, else your future PR might still have the same issues.
116 (other comment)
Merged #110 instead.
117 (other comment)
Kindly sync your master with the team repo and rebase this branch on top of the latest master, dropping the merge commits along the way as well. The current state of the PR has both unnecessary and also wrong changes.
118 (other comment)
If you look at the commits you're trying to merge, there's 5, only the last 2 are really relevant. The merge commits when you merge master into this branch can very easily clutter up the commit history, making it hard to find bugs later on. If you do not want to rebase, try to avoid merging unless you need to resolve conflicts. Otherwise, a rebase is a good idea to keep the git history linear. I will elaborate on the problematic code in the review.
119 (other comment)
you need to fix your git history, you're recommitting past commits and changing the git history. it will cause trouble for the reposense tracking
120 (other comment)
@branzuelajohn after merging this you should be able to rebase your branch on top of it and be able to merge #137
@onnwards (104 comments)1 (commented on others PR)
shouldn't this be resumes from step 2, like in UC1b below?
2 (commented on others PR)
what defines a conflict? overlapping datetime + same name? or overlapping datetime + same doctor? or both? or are there other cases where a conflict will arise?
In the same vein, how specific should we be for Use Cases?
3 (commented on others PR)
Think all the 1a's and 1b's can be summarised somehow since its being repeated in all use cases, but I'm not sure how to handle it. does *a work? or use inclusion with a bigger use case? -
1. user enters a command
2. system reads the command and executes the command
1a. invalid command
1b. invalid subcommand
4 (commented on others PR)
might want to consider changing to something like this?
steps 1a1 to 1a2 are repeated until command entered is correct/free from errors.
same thing for the other loop-style/invalid input by user use cases
5 (commented on others PR)
1c, 2a looks to be repeated as well in edit and find (1c), and edit and delete (2a)
6 (commented on others PR)
@AY2021S2-CS2103-W17-2/developers
7 (commented on others PR)
should it extend Exception or RuntimeException? any particular reason for making this an unchecked exception?
8 (commented on others PR)
same for NegativeOrZeroDurationException, AppointmentConflictException
9 (commented on others PR)
is this an intended mention of addressbook.json here?
10 (commented on others PR)
maybe consider a naming more similar to UniquePersonList.java, and same ordering of methods as UniquePersonList.java
11 (commented on others PR)
not sure whether this is allowed under coding convention for spacing
12 (commented on others PR)
this doesn't look like it fits the regular format of implementing Parser>DeleteAppointmentCommand>
13 (commented on others PR)
think u may have missed a param INDEX?
command should be something like edit-appt 1 pt/2, which means:
edit first appointment (right side of GUI),
change the patient in the appointment to the second patient in the patient list (bottom left side of GUI)
check out editPatientCommand regarding this.
14 (commented on others PR)
i don't think this is true, if this were true then each patient would only be able to have 1 appointment at any point in time.
15 (commented on others PR)
why allMatch? this doesn't sound like it would work.
with allMatch(), wouldnt it mean all appointments in the appointment schedule have to be the same appointment for this to return true?
this sounds like it should be anyMatch instead, in which case the original contains() should be used
16 (commented on others PR)
i think leaving as List>Appointment> may fit the current coding convention better, All previous commands like DeletePatientCommand, EditPatientCommand uses List>Person> as well
17 (commented on others PR)
agree,
rationale is that for a scheduling conflict to happen, either patient has overlapping timeslot, or doctor has overlapping timeslot,
think this method wouldn't work, and hasConflict should be used instead
18 (commented on others PR)
same issue here with allMatch(), should use hasConflict instead
19 (commented on others PR)
i think the issue is that the current editContains is using allMatch(), which i don't think is correct?
from my other comment on this, all appointments in the schedule have to return true for equals() for allMatch to return true, which doesn't seem to be the right idea
20 (commented on others PR)
this code would not work if patientIndex didn't exist. Should handle it like lines 104-106: ie. something like
Person patient = editAppointmentDescriptor.getPatientIndex().isPresent()
? displayedPatientRecords.get(editAppointmentDescriptor.patientIndex.getZeroBased())
: appointmentToEdit.getPatient();
21 (commented on others PR)
this method name sounds like you're converting a Set>String>, instead of converting to a Set>String>. Would recommend to change to convertToStringSet or something along those lines
22 (commented on others PR)
is there a need to 8 spaces then 8 spaces again? im not too sure about the coding convention
23 (commented on others PR)
what's the rationale behind trimming? code looks like it should work without trimming right?
24 (commented on others PR)
programming to an interface is better coding practice if you don't need to use any ArrayList specific methods: ie.
List>String> xxx = new ArrayList>>(); instead of ArrayList>String> on the LHS
25 (commented on others PR)
combine?
String keywords = argMultimap.getValue(prefix).get();
26 (commented on others PR)
this may be just me but i feel like doing the object creation on another line feels v messy...
i'd rather do Collections.addAll(tagKeywords, listKeywords(argMultimap, PREFIX_XX));, but its up to u!!
27 (commented on others PR)
think this portion should refer to both appointment schedule and patient records, not just patient records
28 (commented on others PR)
is there a need to separate the predicates PREDICATE_SHOW_ALL_PERSONS into Patient and Doctor for better clarity? since in this command we are supposedly only showing all patients, not all persons
29 (commented on others PR)
same question with the separation into doctor/patient for this
30 (commented on others PR)
believe this may change to just Predicate>Patient> if we don't use the Predicate>Person> in Model.java (change will populate downwards)
31 (commented on others PR)
abstract class?
32 (commented on others PR)
propose changing the name of this class as well since it only affects data for patients.
on a side note, i think we will need to create a sample appointment data util to populate sample data for appointments as well. will add this in the issue tracker.
33 (commented on others PR)
may be able to make this abstract as well
34 (commented on others PR)
Accidental use of Patient here.
can probably remove the initialisation and stick with only the declaration if abstract class is used
35 (commented on others PR)
should change AddressBookStorage here to AddressBookStorage>Patient> to avoid future confusion with AddressBookStorage>Doctor> when it is added into this method
36 (commented on others PR)
to change naming of the json file itself, same for the other test jsons,
unless intention was to leave it as PersonAddressBook.json because should be clear enough that it is meant for patients because it is in a JsonPatientRecordsStorageTest folder. (but i still think renaming would be clearer)
37 (commented on others PR)
to update comment
38 (commented on others PR)
small issue that doesn't affect anything but the param name is still addressBookFilePath
39 (commented on others PR)
consider refactoring method names?
40 (commented on others PR)
I don't think so? I think this should be a class that tests for all versions of addressbook? because this would correspond to the main class AddressBook.java, which is for both doctors and patients right
41 (commented on others PR)
yup i think so
42 (commented on others PR)
does this imply that force delete must be before patient index? ie. command must be given as delete-patient --force 1
if it does, is it intended?
if yes, then i may be better to specify maybe in the force delete message
43 (commented on others PR)
i believe this portion of the code doesn't have to be in a try?
i think its cleaner to move it out of the try if it doesn't have to be inside.
u can then handle the isForceDelete cleaner as well (ie maybe in the else)
44 (commented on others PR)
actually, i think a cleaner way may be to check the index first, if index is wrong then throw a parse exception for index related stuf (ie DeletePatientCommand.MESSAGE_USAGE, only after index is confirmed to be good, then parse for forceDelete.
this is because currently the emphasis of the parse exception message usage being returned isn't very clear,
ie if user keys command delete-patient --force notAnIndex, this method returns a ParseException with FORCE_DELETE_MESSAGE_USAGE. Emphasis of the exception should have been on the Index being wrong instead,
45 (commented on others PR)
should edit the method name to indicate that this method is for empty appointmentschedule, non empty patient records
46 (commented on others PR)
same here, method name is wrong, should be execute_nonEmptyAppointmentScheduleNonEmptyPatientRecords_failure or something along those lines
47 (commented on others PR)
yeah that does sound abit ugly.
i'd prefer just the 1 line (or multiple lines) which causes the exception to be within the try, so it makes it clearer for readers too
48 (commented on others PR)
would be good if FORCE_DELETE_REQUIRED is renamed to FORCE_DELETE_PATIENT_REQUIRED as well
49 (commented on others PR)
refactoring error here
50 (commented on others PR)
why wasn't this previously in ah, is it because this would be used for the statusbarfooter (which currently only shows appt schedule storage filepath)?
51 (commented on others PR)
shouldn't we just call this PATIENT INDEX instead of PATIENT (positive integer)?
52 (commented on others PR)
minor, but should be have 😆
53 (commented on others PR)
should be find-doctor, probably means FindPatientCommand may be wrong as well.
54 (commented on others PR)
note to @onnwards to add hasConflictingUuid checks
55 (commented on others PR)
note to modify according to clear-patient bug
56 (commented on others PR)
note to modify according to delete-patient bug
57 (commented on others PR)
note to @onnwards to modify according to edit-patient bug
58 (commented on others PR)
need to update javadocs
59 (commented on others PR)
update javadocs, probably means javadocs is wrong for EditPatientCommand as well
60 (commented on others PR)
AddDoctorCommand object instead. probably means that AddPatientCommandParser is wrong as well, and potentially AddAppointmentCommandParser
same for all mentions of AddCommand in this file
61 (commented on others PR)
same for all the EditCommands here as well
62 (commented on others PR)
this file is not supposed to be here and should be deleted
63 (commented on others PR)
javadocs here, and below as well
64 (commented on others PR)
needs javadocs update in this file, for patientrecords as well
65 (commented on others PR)
why??
66 (commented on others PR)
why no override?
67 (commented on others PR)
note to @onnwards for UUID
68 (commented on others PR)
why though? is there a rationale behind it @Jacob-Pang
looks like its because we can get more abstraction with an abstract class?
69 (commented on others PR)
just noticed, weird indentation for this line for javadocs
70 (commented on others PR)
javadocs for this and probably also JsonPatientRecordsStorage.java
71 (commented on others PR)
seems to be inconsistent with the overall order of userprefs, patient, doctor, appointment
72 (commented on others PR)
here too
73 (commented on others PR)
will there be any side effects of renaming this? any other places in the code that we need to change? not very familiar with the Json storage conventions
74 (commented on others PR)
again quite minor, but inconsistent order?
75 (commented on others PR)
note to @onnwards to Predicates to resolve merge conflict properly
76 (commented on others PR)
jdocs, same problem for AddPatientCommandIntegrationTest.java
77 (commented on others PR)
note: to modify test classes here to test correctly after delete-patient/delete-doctor bugfix has been implemented
78 (commented on others PR)
jdocs
79 (commented on others PR)
jdoc
80 (commented on others PR)
should not be a remove and an add, and line 34 looks like it should fail: comparing AddressBook>Patient> with AddressBook>Doctor>
81 (commented on others PR)
refactoring error
82 (commented on others PR)
recommend to change to a more doctor sounding name for consistency's sake
83 (commented on others PR)
jdocs for patient
84 (commented on others PR)
jdocs for patient to change to doctor
85 (commented on others PR)
why not the straight up import?
86 (commented on others PR)
some refactoring issues in this file, need to rewrite these methods since we now have 3 different things to get from
87 (commented on others PR)
an update to the TypicalAppObject's objects will probably require an update to the corresponding json (typicalDoctorRecords.json, typicalAppointmentSchedule.json) as well.
88 (commented on others PR)
@Jacob-Pang any ideas on why this isn't failing tests?
89 (commented on others PR)
shouldn't the typing of addressbook fail the equals? because we are comparing >Patient> with >Doctor> right
90 (commented on others PR)
this extra = misaligns it 😢
91 (commented on others PR)
javadocs has mention of patient
92 (commented on others PR)
actually, i feel like we should throw an exception if forceDelete not equals "--force" as well? feels like we shouldn't just let a user pass with an input such as delete-patient aisjdhabakahbakshdbankdjashb 1
if we do this we can then make the inner if conditional not nested, and more flat
same for DeleteDoctorCommandParser
93 (commented on others PR)
ah i missed that out, yeah then it works perfectly
94 (commented on others PR)
if timeInput == null then null is returned, which will lead to a NullPointerException in the method calling this one
95 (commented on others PR)
can try to use Matcher instead, check out sebastian's PR on how he uses Matcher.compile for forceDelete and patientIndex. exceptions can then be handled that way.
with this, it probably means you won't get an index out of bounds exception, or nullpointer exception with the input, makes stuff cleaner
96 (commented on others PR)
a NullPointerException shouldn't be thrown, because the caller method don't handle it. should throw ParseException instead. also NullPointerExceptions technically shouldn't be thrown/caught either since they're runtime exceptions, not checked exceptions.
97 (commented on others PR)
it would be better if this was more explicit to facilitate/improve resuability by someone who doesn't know regex, maybe something like DD_SLASH_MM_SLASH_YY, etc
98 (commented on others PR)
i don't think there's a need to have a new class for this? i think it is fine to have these constants be in TimeslotParser.java
@Jacob-Pang for input
at most, i would probably make it an enum with a field, ie
enum TimeslotRegex {
DATE_SLASH_SHORT ("([0-9]{2})/([0-9]{2})/([0-9]{2})"),
DATE_SLASH_LONG ("([0-9]{2})/([0-9]{2})/([0-9]{4})"),
DATE_DASH_SHORT ("([0-9]{2})-([0-9]{2})-([0-9]{2})"),
DATE_DASH_LONG ("([0-9]{2})-([0-9]{2})-([0-9]{4})");
private final String regex;
private TimeslotRegex(String regex) {
this.regex = regex;
}
public String getRegex() {
return regex;
}
}
you could then access the first regex by: TimeslotRegex.DATE_SLASH_SHORT.getRegex()
you could even take this a step further by having an abstract method in the enum, eg. maybe formatterExpression, with each indiviudal enum having their own implementation of formatterExpression (returning a different formatter string) so you could shorten the if/elseif testing in parseFormat
99 (commented on others PR)
have you tried javafx.scene.input.KeyCombination
100 (commented on others PR)
i think calling this addInput would be clearer
101 (commented on others PR)
would be cleaner if this was this.inputCommandList = new ArrayList>>();
then line 10 can then be private static List>String> inputCommandList
102 (commented on others PR)
pointer should reset back to the end of the list right? instead of just ++
103 (commented on others PR)
this feels like it could be cleaner.
public static String retrieveInput(boolean upPressed) {
if (upPressed) {
incrementPointer();
} else {
decrementPointer();
}
return getCurrentInput();
}
public static void incrementCurrentPointer() {
if (currentPointer < inputCommandList.size() -1) {
currentPointer++;
}
}
public static void decrementCurrentPointer() {
if (currentPointer > 0) {
currentPointer--;
}
}
public getCurrentInput() {
return inputCommandList.get(currentPointer);
}
it doesn't matter whether you abstract it into a function or not like above, but the conditionals can be simplified
104 (commented on others PR)
u can just omit the else if nothing is going to be written
105 (commented on own PR)
don't think so, logic is we don't want any patient commands to affect appointment schedule, so we make a new typicalAppointmentSchedule here
106 (other comment)
still missing some sections to UG, like the summary table, so will not close issue yet.
107 (other comment)
fixes #6
108 (other comment)
duplicate PR with #26
109 (other comment)
you can perform the CI checks locally by using .\gradlew build
110 (other comment)
is this PR still relevant? @icytornado
111 (other comment)
to solve:
recommend 2 prs:
raise exception if appt list has the patient being deleted,
- recommend to add `--force` (or whatever) parameter, force delete feature:
- if `--force` is specified then cascade the deletion
112 (other comment)
3 ways:
>s>1. change patient class to have mutable fields (and potentially appointment class)>/s>
>s>2. couple the patient class to appointment class such that edit-patient will also perform edit-appt>/s>
113 (other comment)
@ivantjh (84 comments)1 (commented on others PR)
Remove empty space on new line >_>
2 (commented on others PR)
Formatting!
3 (commented on others PR)
Swap the parameters to be consistent with the rest of the assertEquals
4 (commented on others PR)
nitpick: that should be named other iirc
5 (commented on others PR)
No need else clause here. Can reduce the indentation level.
6 (commented on others PR)
Its not exactly a nameString. Rename to searchString
7 (commented on others PR)
Got better name? I think calling it anniversary would feel better other than date.
8 (commented on others PR)
return time == null, no need to store another instance variable.
9 (commented on others PR)
Can just check using time == null
10 (commented on others PR)
No space between Event and (
11 (commented on others PR)
nitpick: no need else clause, just return
12 (commented on others PR)
Style violation, supposed to be 8 spaces from the preceding line.
13 (commented on others PR)
I think better to store as LocalDate. Can use #41 dateUtil to make it easy.
14 (commented on others PR)
Use DateUtil.fromDateInput(...) to get back a LocalDate. Use that to create Birthday. This will not change the tests that were already written.
15 (commented on others PR)
Wrong comment. Should be {@code Birthday}
16 (commented on others PR)
Probably can do the dateUtil parsing here too
17 (commented on others PR)
Yes, we should still do it. I added some comments to the test files. Essentially, when we create the test objects, we parse the dateStr to a LocalDate using the util methods. i.e. withBirthday(...) takes in a dateStr, parses that string and returns a new Birthday with a LocalDate in it.
18 (commented on others PR)
I think this should be in the present tense. if they are not in it
19 (commented on others PR)
Can be shortened to
return Arrays.stream(arr)
.map(ParserUtil::parseIndex)
.collect(Collectors.toList());
20 (commented on others PR)
I think there should be a space between the arrow heads. updateFilteredPersonList(x -> group.getPersons().contains(x))
21 (commented on others PR)
Wrong indentation, change intellij settings
22 (commented on others PR)
Having a parameter here is out of the norm. Can add a comment here saying that it requires the actual personList serialised from the persons json file?
23 (commented on others PR)
Multi-line for readability. I think the lambda has a spaces enclosing the arrowhead.
24 (commented on others PR)
Not optional parameter. This line should be + PREFIX_INDEX + "INDEX"\n
25 (commented on others PR)
Should we have the command name be del-date? Easier to type a shorter command
26 (commented on others PR)
I think this could be better.
LocalDate xRelative = x.compareTo(now) < 0 ? x.plusYears(1) : x;
LocalDate yRelative = y.compareTo(now) < 0 ? y.plusYears(1) : y;
return xRelative.compareTo(yRelative);
27 (commented on others PR)
Can we have date.setText(personEvent.toUi())? Makes it easy to test the formatting later on
28 (commented on others PR)
We should store the localDate here instead of taking only the day and month. Easy to change formatting later on.
29 (commented on others PR)
Should have a toUi method here to do the formatting using the LocalDate formatter methods.
30 (commented on others PR)
PersonEvent should have no knowledge of Birthday and Event classes, put these two helper methods in their respective methods. They could be named toUi() too.
31 (commented on others PR)
So for here, it will just be person.getDates().forEach(event -> personEvents.add(new PersonEvent(event.getDate(), person, event.toUi())
32 (commented on others PR)
person.getBirthday().getBirthday() is very strange >_>. Can rename to the last getBirthday() method to getDate()?
33 (commented on others PR)
Rename to getDate()
34 (commented on others PR)
Ok, got it. Lets leave it here first
35 (commented on others PR)
👍
36 (commented on others PR)
Is this still temporary?
37 (commented on others PR)
Should this be date.toUi()?
38 (commented on others PR)
Possible to create another component to store the profile picture? The same code is used in PersonDetailsCard and PersonCard.
39 (commented on others PR)
I think you have to write the b/ prefix stands for. I think we can leave birthday there. Users should know to supply a date from the examples below.
40 (commented on others PR)
Would this be better? Can optionally provide a group name to list all friends in that group
41 (commented on others PR)
I think we should still put Birthday here
42 (commented on others PR)
Would be good to write docs on the specifics for Event and Picture as it is not clearly shown in the class diagram. Like the multiplicity of Person to Event (1 to *) and multiplicity of Person to Picture (1 to 0..1)
43 (commented on others PR)
I think would be good to document something the rationale for this
44 (commented on others PR)
Ok, btw I was talking about the usage of a single Person in the detailedPerson observable list. That one probably need to document the rationale for it.
45 (commented on others PR)
Can just do static import, then it will look like private final Frequency frequency
46 (commented on others PR)
Should use static import
47 (commented on others PR)
This runs goal.getNext() with the lastest meeting date? If it is, should probably write.
Date latestMeetingDate = meetings.stream()
.map(Event::getDate)
.filter(x -> x.isBefore(date)
.max(LocalDate::compareTo)
.orElse(DateUtil.ZERO_DAY);
return goal.getNext(latestMeetingDate);
48 (commented on others PR)
Need follow the style guide, don't use this in instance methods if there is no need to. Link here
49 (commented on others PR)
I don't think method name is clear enough. getNextMeetingCutoff would be better. Open to suggestions too!
50 (commented on others PR)
Can we encapsulate the ENUM_MAP so we could change implementation later on? Goal.isValidFrequencyString(frequencyString) would be a better API
51 (commented on others PR)
Same for this. Goal.getFrequency(frequencyString) would probably be better.
52 (commented on others PR)
Another way would be to convert into one method Goal.parseFrequency(frequencyString) that throws an exception if the frequencyString is invalid. I would prefer this as it would reduce the API exposed from Goal.
53 (commented on others PR)
Should use Frequency frequency here
54 (commented on others PR)
String frequencyStr = argMultimap.getValue(PREFIX_FREQUENCY).orElse("n")
frequency = ParserUtil.parseFrequency(frequencyStr)
55 (commented on others PR)
The parseException from ParserUtil.parseFrequency(...) not caught here >_>
56 (commented on others PR)
Goal.fromGoalString(goal.toLowerCase(Locale.ROOT) would be better. Can hide ENUM_MAP
57 (commented on others PR)
person.getGoal().isNoneFrequency() would be better. Can hide the implementation away from UI
58 (commented on others PR)
👍
59 (commented on others PR)
Format: set-goal INDEX f/FREQUENCY can just use back ticks.
60 (commented on others PR)
Where is the new ThemeCommandSequenceDiagram.png?
61 (commented on others PR)
Oops, my bad.
62 (commented on others PR)
This looks really weird. I think it would be better to just have two separate commands and parsers for add-debt and subtract-debt.
63 (commented on others PR)
Should have two different commands for add-debt and subtract-debt
64 (commented on others PR)
No need to have conditionals here if have two separate commands
65 (commented on others PR)
What if negative value?
66 (commented on others PR)
I think u are missing the formatter for 2dp. Need to pad with zeros for 2dp if float has only a single dp
67 (commented on others PR)
Can we follow the order for initialisation according to the data fields order declared above?
public Person(Name name, Phone phone, Email email, Birthday birthday, Address address, Picture picture,
Debt debt, Set<Tag> tags, List<Event> dates, List<Event> meetings)
68 (commented on others PR)
Follow attributes order
69 (commented on others PR)
😢 inconsistent ordering from Person.java for attribute order
70 (commented on others PR)
Shouldn't debt be after picture following the order from Person.java
71 (commented on others PR)
Negative debt is valid? 👀
72 (commented on others PR)
Should follow test method names for here, add() and subtract() command below
73 (commented on others PR)
Shouldn't this debt be below picture
74 (commented on others PR)
Debt probably has to be formatted with $ sign and 2 dp. Could do debt.setText("Debt: " + person.getDebt().toUi())
75 (commented on others PR)
toString() could be used for debugging etc
76 (commented on others PR)
Ok, got it! I think better document it here because it is weird that only the ChangeDebtParser takes in a boolean.
77 (commented on others PR)
Ahh, the constructor of Debt rejects the init.
78 (commented on others PR)
Ok! Should document that you can record negative debt in Debt class to signify that the user of FriendDex owes money to the person instead.
79 (commented on others PR)
Can add a TODO comment here so we can refactor this if got time? The rest looks ok!
80 (commented on others PR)
nitpick: should add a new line here for readability.
81 (commented on others PR)
Newline here for readability.
82 (commented on others PR)
Do static import here
83 (commented on others PR)
This is to account for the meeting added today? Write comment above saying that the latestMeetingDate includes today
84 (commented on others PR)
Need remove
85 (commented on own PR)
Person is still immutable, the setters are not changing the Person itself. Will change it to withDates instead of setDates because the set prefix is commonly associated with mutability.
86 (commented on own PR)
This should work for asdf.tar.gz. .gz will be extracted from the function and validated.
87 (commented on own PR)
I think its ok here because we are deleting the filePath of a picture.
88 (commented on own PR)
Nope, this is still used when the Person being initialised has no meetings and no dates.
89 (commented on own PR)
yeap, my bad
90 (commented on own PR)
👍 too late alr
91 (commented on own PR)
Will add as an issue first!
92 (other comment)
Lgtm!
93 (other comment)
Would be good for Event to use a LocalDate instead of String to represent date.
94 (other comment)
#41 fixes this
95 (other comment)
According to the updated image, the help command doesn't show a popup? I was expecting something like this with the new url.
96 (other comment)
Fixed with #97 and #98
97 (other comment)
Yeap, that's correct. I think you can think of it as weekly homework. If I were to complete my weekly homework on Monday when it is supposed to be due on Friday, I don't want the following week's homework deadline to be shifted to next Monday.
@samuelfangjw (79 comments)1 (commented on others PR)
I think this phrasing would be better.
in a university to keep track of people they have crossed paths with. It is optimised for use via...
2 (commented on others PR)
I think putting my full name here will be better! (consistent with the other names)
Fang Junwei, Samuel
3 (commented on others PR)
perhaps we can change the phrasing of the roles for all of us to In charge of .... e.g. In charge of documentation, In charge of Integration. Currently the role sections sound a bit weird for all of us.
4 (commented on others PR)
Perhaps Tests instead of test would be better here.
5 (commented on others PR)
typo in MIT Licence
6 (commented on others PR)
We should consider ordering the glossary alphabetically. I think that was the initial ordering.
7 (commented on others PR)
Missing period.
8 (commented on others PR)
I think this is fine for v1.2 but let's add an issue to add support for different date formats, especially since output format and input format are different.
9 (commented on others PR)
Is there a need for taskType?
Seems like a hacky way to keep track of subclass name and might not be best practice. We should instead be looking to utilise polymorphism to distinguish the different classes. If absolutely necessary, this should be an enum with final access modifier so there is no chance to change once assigned.
10 (commented on others PR)
Currently isDone boolean might not make sense, given that we have split task into completable and (possibly recurring) events. This would imply that only tasks that are a Completable should be completable. Perhaps this should go in the completable class instead.
11 (commented on others PR)
I don't believe there is a need for the toString method here since it is overridden in all it's subclasses. The body of this function will never be called. Might be better to make this an abstract method with no body.
12 (commented on others PR)
In the original model discussed, Completable was an abstract class with subclasses todo and deadline (or possibly a deadline with optional date field). Is there a reason for the change?
13 (commented on others PR)
Missing a period.
14 (commented on others PR)
"Interval should be one of: ..."
15 (commented on others PR)
dd-MM-yyyy
16 (commented on others PR)
add requireNonNull(event);
17 (commented on others PR)
should require non null here
18 (commented on others PR)
Is there a need to return new EventList? Would it be better to return this instead. If immutability is desirable we can change it to only be able to access an unmodifiable event list.
19 (commented on others PR)
Add period after each sentence, and perhaps give a short description of the param.
20 (commented on others PR)
put the return inside the try catch block. try { return Interval....}. In general, good to avoid returning outside the try catch block unless necessary as it's easier to read (usually if you have to it might be better to abstract out the try catch block in a method).
21 (commented on others PR)
same here, return inside try catch block.
Let's use yyyy instead of uuuu for better compatibility (with for e.g. simple date parser.)
22 (commented on others PR)
Let's call the encode/decodeDate methods in commons.DateUtil class instead. Feel free to add the date formatter for that one so it matches dd-MM-yyyy.
23 (commented on others PR)
This doesn't display very nicely when printed in UI, let's add some newlines and whitespace.
24 (commented on others PR)
use requireAllNonNull method instead
25 (commented on others PR)
great! for anyone else checking getZeroBased() method checks for negative indexes alr 😃
26 (commented on others PR)
is creating a new project necessary?
27 (commented on others PR)
Would it be better to move this check to TodoList for better abstraction.
28 (commented on others PR)
I've set the observable list to track any changes to the participant list, returning a new project might mess this up. I'll check on my end and change this to a mutable version if needed.
29 (commented on others PR)
Missing check for projectsFolder, but no worries i can correct in my next pr since it's my mistake.
30 (commented on others PR)
blank line
31 (commented on others PR)
blank line
32 (commented on others PR)
blank line
33 (commented on others PR)
blank line
34 (commented on others PR)
blank line
35 (commented on others PR)
might be better to name the test parseCommand_addDto_success since we are only testing the success scenario here. As per https://se-education.org/guides/conventions/java/intermediate.html, we should only leave our the expected behaviour if we are testing for all scenarios.
36 (commented on others PR)
I think it would be better to add a check whether two objects which are equal have the same hashcode. This fulfils the second point of the hashcode contract as stated in https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Object.html#hashCode().
Also fyi it's not really necessary to check that different objects have different hashcodes (not part of the hashcode contract) but i think it's ok to leave it in this case!
37 (commented on others PR)
Should also check that same object -> same hashcode.
38 (commented on others PR)
check for equals too! this is more impt than not equals as it's part of the hashcode contract.
39 (commented on others PR)
Minor comment, maybe can use the indexes in typical indexes.
40 (commented on others PR)
same here check for equals!
41 (commented on others PR)
same here
42 (commented on others PR)
check equal objects same hashcode
43 (commented on others PR)
here too
44 (commented on others PR)
"The update project command and the update contact command are relatively straight forward."
This line doesn't really add much value, can consider removing
45 (commented on others PR)
typo in projecct.
Also can consider styling it. UpdateProject command is executed
46 (commented on others PR)
typo "abd"
47 (commented on others PR)
Not very sure what is meant by "We must ensure that the implementation of each individual command are correct.", maybe can rephrase.
48 (commented on others PR)
Demeter's law! Probably find for now since we did similar things in other areas, but I think we should file an issue and 1 shot change all.
49 (commented on others PR)
different deadline here
50 (commented on others PR)
typo here
51 (commented on others PR)
Square brackets are for optional parameters, the parameters here do not seem to be optional during testing.
52 (commented on others PR)
UpdateProjectCommand should be in caps
53 (commented on others PR)
@param index The index of the project.. would be better
54 (commented on others PR)
Typos in command name.
55 (commented on others PR)
Period at end of javadoc.
56 (commented on others PR)
period at end of javadoc
57 (commented on others PR)
This message should be for UpdateProjectCommand.
58 (commented on others PR)
Please use the name of the updated project instead. The toString method of update project does not look good on the UI.
59 (commented on others PR)
Let's also standardise the naming of parameters with the addP command.
60 (commented on others PR)
End sentence with period, class names should be in {@code} to standardise with other comments as much as possible.
61 (commented on others PR)
Same here
62 (commented on others PR)
This message can be improved, please refer to deleteE command and standardise the formatting with that.
63 (commented on others PR)
was PREFIX_INDEX used for anything previously?
64 (commented on others PR)
Parameters should be optional, refer to EditCommand. There should be at at least one field provided.
65 (commented on others PR)
index should be non null as well.
66 (commented on others PR)
Please use the Index Class instead
67 (commented on others PR)
Add a method to Project, this line violates demeter's law.
68 (commented on others PR)
projectToUpdate would be a better name
69 (commented on others PR)
should be AddContactCommand
70 (commented on others PR)
should be groupmate in projects
71 (commented on others PR)
groupmates
72 (commented on others PR)
groupmates
73 (commented on others PR)
Groupmate
74 (commented on others PR)
groupmates
75 (commented on others PR)
group mate builder
76 (commented on others PR)
groupmate builder
77 (commented on others PR)
typo should be time
78 (commented on others PR)
time repeated twice
79 (commented on others PR)
If it's weekly maybe better to show the day instead of the date.
80 (commented on own PR)
agreed. just realized the original AB3 does not use spaces consistently, might be worth addressing this in a future pr?
81 (commented on own PR)
agree with this, will make changes and update the pr
82 (commented on own PR)
thanks! @vevek
83 (commented on own PR)
I couldn't get the StackPane to have 0 min height with other methods but you're right, it looks a bit odd here. Let me look into this properly.
84 (commented on own PR)
agreed
85 (commented on own PR)
agreed, will check the other images and relabel them accordingly too.
86 (commented on own PR)
Using the american spelling color instead for consistency
87 (commented on own PR)
resolved by setting minWidth/Height as necessary. This stops the panes from fully "disappearing" when resizing panes.
88 (commented on own PR)
Current resolution updated to 1280x720 for better compatibility
89 (commented on own PR)
Waiting for your PR @vevek, which would have implemented the required types.
90 (commented on own PR)
Not my comments, copied from person haha
91 (commented on own PR)
can confirm no issue here, if target and edited are not the same, and current list already contains new edited project, then the project is duplicated.
92 (commented on own PR)
This was copied over from person class. Has same functionality as RuntimeException.
93 (commented on own PR)
i believe null values will be converted to "null" in json, but i agree there should be a better way.
94 (commented on own PR)
following the structure of addressbook,
addressbook contains personList contains persons.
similarly,
ProjectFolder contains projectList contains projects.
95 (commented on own PR)
good spot should remove the space at the end
96 (commented on own PR)
yeap surprised my checkstyle didn't catch that. thanks!
97 (commented on own PR)
ok i might have been wrong on this, i think null should work. i'll change it on my end.
98 (commented on own PR)
Completable utilises polymorphism. Alternatively, can have an attribute that is null if it's a todo.
99 (commented on own PR)
This was copied over from the AddCommand. I agree with you, maybe we should open an issue and fix all of them at once?
100 (commented on own PR)
Similar to comment above
101 (commented on own PR)
yup good spot.
102 (commented on own PR)
Require non null doesn't return a boolean value. Also I think it's better to leave it as this, seems much clearer to me.
103 (commented on own PR)
This was copied over from AB3, what do you suggest instead?
104 (commented on own PR)
I think the messages have already been abstracted out to one class for messages that are not specific to a class. We should stick to this for now, can consider other implementations in the future
105 (commented on own PR)
Oxford comma is a stylistic choice, I think we should standardise with or without. I'll reword the to prevent ambiguity.
106 (commented on own PR)
Using COMMAND_WORD allows the CommandWord to be changed easily.
107 (commented on own PR)
This test checks that the createFile command does not throw an error when the file already exists
108 (commented on own PR)
Not repeated one for persons one for projects
109 (commented on own PR)
see above
110 (commented on own PR)
dp refers to elevation as per comments, i think is fine for now. If not it'll be DP_COLOR_LOWEST, DP_COLOR_SLIGHTLY_HIGHER, DP_COLOR_SLIGHTLY_SLIGHTLY_HIGHER, which is not sustainable
111 (commented on own PR)
yeap good catch, this should be changed
112 (commented on own PR)
No need, only once we implement edit event list. (YAGNI principle)
I want to try an immutable design for events, todos, deadlines in another PR
113 (commented on own PR)
good call
114 (commented on own PR)
Actually, now that i think it i think it's ok to leave it like this. I feel CompletableDeadlineCard should deal with UI elements (what to display when the item is completed), and Todo class should stick to containing fields related to a todo object (boolean value of whether it's done or not).
115 (commented on own PR)
This so in the future if we want to change how a completed todo is supposed to look we just need to change the UI
116 (commented on own PR)
alright i'll make a quick change
117 (commented on own PR)
Agreed, thanks for being thorough.
118 (commented on own PR)
Changed it to contacts to be more consistent with the other level 3 heading (projects). Do you think this is ok?
119 (commented on own PR)
ID was left out intentionally, copied this method from another handle object. Purpose of this is to compare this handler object to another completable deadline, which doesn’t have an id. I’ll look into changing the naming for these methods to clear things up.
120 (commented on own PR)
This one a bit tricky. I decided on UiCommand since the Ui works with a generic UiCommand (it doesn't know about the subclasses).
121 (commented on own PR)
but not sure which ones clearer
122 (commented on own PR)
How about I edit this to mention calling the overwritten method using polymorphism? Will that be better?
123 (commented on own PR)
Ah ur right, good spot!
124 (commented on own PR)
yes, only can tick off using mark as done.
125 (commented on own PR)
ID is not used in the overview section.
126 (commented on own PR)
sure
127 (commented on own PR)
Card to display UI elements (either tick to empty), deadline class will not do UI related stuff.
128 (commented on own PR)
So each card has 2 constructors, one with an ID (if we need to display the ID so user can select it) and one without, for the overview section where no id is required.
Why not have ID's for both?
I'm afraid users will get confused. I also don't want the users to be able to run commands on tasks in the overview section, as this might lead to confusion.
129 (commented on own PR)
Good spot haha, will update the other occurrences too.
130 (commented on own PR)
@vevek I went ahead and changed occurrences of REPEATABLE to EVENT, I think this makes it clearer.
131 (commented on own PR)
This is handled by throws statement in the method header. Would it be clearer if i explicitly caught and then threw it again?
132 (commented on own PR)
issue will be resolved in #215, together with other commands that have been updated recently
133 (commented on own PR)
Yes, i've made more space for the day label. Tried both, i decided this looks nicer.
134 (commented on own PR)
Spotted this, left it because it was the original implementation. I'll go see if i can change this real quick.
135 (commented on own PR)
fixed
136 (commented on own PR)
Think this will take a little longer to fix (requires changing type of backing list & related methods). I suggest we push this to 1.4 and focus on 1.3 deliverables what do you think?
137 (other comment)
seems like the ci is failing due to checkstyle issues
ERROR:../docs/UserGuide.md:213: no newline at EOF.
WARN:../README.md:15: trailing whitespace.
138 (other comment)
Just realised you accidentally changed the user guide instead of the readme haha! Might want to edit the title 😃
139 (other comment)
Updated user guide with view and undo/redo command and changed some references of AB3 to CoLAB. See #9.
140 (other comment)
@samuelfangjw Looks great! Please add the changes you have added to features to the table of contents.
Done! Forgot to update the table of contents when resolving the merge conflict. How does the latest commit look?
141 (other comment)
Tutorial PR irrelevant to project.
142 (other comment)
Which images are you referring to? @vevek
143 (other comment)
@vevek XR claims credit for finding 😂
144 (other comment)
LGTM.
haha thanks but it's still a draft pr! i'll make some edits tmr and change the pr status when I have something decent 😃
145 (other comment)
Are you able bring back the v1.1 milestone?
can add to v1.1 (there is a closed tab when you click on milestones). if someone wants to do it now i think is ok to change the milestone to v1.1, else we can just throw it to next iteration.
146 (other comment)
let's add a confirmation message in case users accidentally clear all
147 (other comment)
Will figure this out one of these weekends, need a pc to replicate bug.
148 (other comment)
Need to merge #51 before merging this PR, also need to request to use TestFX library on the forum.
149 (other comment)
latest commit fixes #58
150 (other comment)
Team decided not necessary.
151 (other comment)
Looks good to merge. Minor errors. I suggest adding comments to all the methods now so that it's clearer and won't be a bigger hassle in the future.
Which methods are you referring to? There is no need for javadoc comments on getters and setters. Method with @Override tag inherit javadoc comments from superclass, and there is generally no need to add a javadoc comment unless the behaviour has been modified or there is something of note. e.g. equals, toString, hashcode.
152 (other comment)
I will work on tests and other features over the next few days. If no major issues suggest we merge this soon so other team members can start working on their features.
153 (other comment)
Lowered priority to low as this does not affect correctness of current code and is not time sensitive.
154 (other comment)
Great! Please try to finish at least some of the tests, our codecov score a bit low at the moment. Yes, the UI is not ready yet, I'll do a simple one up later.
I'll take a look at this in a couple of hours, think I saw a few oddities but have to take a closer look.
155 (other comment)
In addition, as pointed out by @Eriksen2411 there should be a blank line between the first line of the javadoc and the params.
156 (other comment)
Ready for review, currently UI a bit lacking but I think it would be better to improve on the UI in another PR. As for tests, a large section cannot be covered now because they involve the UI. Will be able to do it once we merge #61.
157 (other comment)
Tests were failing because tests were adding and modifying the same project list. (our list is not immutable, maybe issue for another time). I've solved this temporarily by creating new project for each test.
158 (other comment)
Ready for review
159 (other comment)
Ready for review
160 (other comment)
General hashcode contract states that
- When hashcode is called repeatedly on an object, should return same result unless object has been modified.
- Two objects that are equal (according to equals method) should return the same hashcode
- Different objects do not have to return the same hashcode, although it's good if it does so.
Wah I never knew there is such a contract. Will do it tomorrow!
For the third point I think it should be the other way round. Objects that are not equal should return different hashcodes as far as possible.
I think it should still be pretty safe to check for different hashcodes for different objects since it should be quite unlikely to collide. Do you think we should remove this check?
Yup, no harm checking since very low chance they collide (int can only represent a finite number of things!)
161 (other comment)
Some minor style issues.
Thanks for pointing this out, wasn't aware there was a style guide for md files. Will look through the style guide again and update.
162 (other comment)
Let's standardise contacts for contacts in the contacts list and group mates for contacts in the project.
163 (other comment)
Updated, please take a look thanks!
164 (other comment)
Currently, I've changed the UI elements to reflect the new groupmates name. However, most of the methods, commands and classes still reflect the participants name. I think better to change in another PR, I've created an issue for this #154.
165 (other comment)
Done for now, will continue looking another time.
166 (other comment)
Maybe 1024 * 768
167 (other comment)
same as #194
168 (other comment)
Removed in #199
169 (other comment)
Resolved, changed to deleteC
170 (other comment)
Thanks! Will work on adding tests in 1.4.
@benedictkhoomw (71 comments)1 (commented on others PR)
Code Quality sounds more like a responsibility. You could put "Developer, VS Code Expert" for your role.
2 (commented on others PR)
Should these @return and @param aliasName have descriptions?
There are similar cases in this and other files.
3 (commented on others PR)
Missing method comment?
4 (commented on others PR)
These look like they shouldn't be here.
5 (commented on others PR)
These look like they shouldn't be here.
6 (commented on others PR)
Are these missing JavaDocs?
7 (commented on others PR)
Is this missing JavaDocs?
8 (commented on others PR)
Is there a link to this source? Also, if you understood and adapted it, consider using
//Solution below adapted from ...
Saw this in a few other files.
9 (commented on others PR)
Should there be a newline between these two methods?
10 (commented on others PR)
Could you add descriptions to these tags or remove them?
11 (commented on others PR)
Could you add descriptions to these tags or remove them?
12 (commented on others PR)
What is object?
13 (commented on others PR)
Please standardize the javadocs format in future to follow the style guide. Will approve first because it's non-breaking and we should merge soon.
14 (commented on others PR)
Perhaps this could be instead shown as an arrow returning to the user
15 (commented on others PR)
Consider using MODEL_COLOR instead of LOGIC_COLOR since this is part of the model component.
16 (commented on others PR)
Should the return arrow be dashed and the activation bar disabled when returning?
17 (commented on others PR)
Perhaps
can then be executed by entering the
Aliasinstead of the full or partial command.
should instead be
can then be executed by entering the alias instead of the full or partial command.
because the user is not typing in Alias but rather the alias that they specified. It's a small semantic point.
18 (commented on others PR)
Are these comments supposed to be here?
19 (commented on others PR)
There may be a missing closing bracket here:
if () then ([all parameters are valid)
20 (commented on others PR)
The tense seems a bit off here.
Maybe this
If the input begins with an existing command word, parses it as one of those pre-defined command.
should be
If the input begins with an existing command word, parse it as one of those pre-defined command.
(italics added). Similarly for the rest of the points.
21 (commented on others PR)
Also consider placing this description above the activity diagram, with a transition to the diagram. E.g.
The following diagram illustrates this flow.
DIAGRAM GOES HERE
22 (commented on others PR)
Consider labeling the arrow returning from UI to user with display commandResult instead of this:
23 (commented on others PR)
I'm not sure but the new keyword may not be appropriate in a sequence diagram. Consider this example from the textbook:
24 (commented on others PR)
Maybe change return result to return commandResult for consistency with the related return statements below.
25 (commented on others PR)
Should this be an IssueList?
26 (commented on others PR)
This activity diagram appears to have the condition within the branching diamond. However, this may not meet requirements for this module. Consider moving the branching conditions out of the diamond as guard conditions in square brackets.
27 (commented on others PR)
Agreed. It may also be good to list out pros and cons for each possible implementation.
28 (commented on others PR)
This looks like commented-out code. Was this intended to be here?
29 (commented on others PR)
There may be a typo here. Did you mean something like this?
Checks that room
03-100is not occupied by anyone.
30 (commented on others PR)
There may be inconsistent tense here.
The problem is reversed if the parent-child roles were swapped.
Maybe this could be changed to either
The problem would be reversed if the parent-child roles were swapped.
or
The problem is reversed if the parent-child roles are swapped.
31 (commented on others PR)
Consider adding a fullstop at the end.
32 (commented on others PR)
It may be good to give a short description on what this example does.
33 (commented on others PR)
It may be good to give a short description on what this example does.
34 (commented on others PR)
Thank you for moving this to its own class. Could you update your PR to close #69?
35 (commented on others PR)
Should there be a blank line between the description and the parameter list? I believe it's in the JavaDocs guide.
Saw this in other files too.
36 (commented on others PR)
Is this class missing JavaDocs?
37 (commented on others PR)
Is this class missing JavaDocs?
38 (commented on others PR)
Perhaps put a @throws NullPointerException ... since you're using requireAllNonNull
Saw this in other files too.
39 (commented on others PR)
Should there be an @param tag?
40 (commented on others PR)
It might be good to document this method too, even though it's an overridden method because each command is different.
41 (commented on others PR)
Should there be a blank line between description and parameters?
42 (commented on others PR)
Should there be a blank line between description and parameters?
43 (commented on others PR)
Should there be a blank line between description and parameters?
44 (commented on others PR)
Perhaps the first letter of the parameter description and return description should be capitalized?
That is,
@param aliasName Name of the alias.
@return Whether the name matches the regex pattern.
Saw this in most other files.
45 (commented on others PR)
Is this missing a @param tag?
46 (commented on others PR)
Is the @param missing a description of the parameter?
47 (commented on others PR)
Is this missing an @return tag?
48 (commented on others PR)
Is this missing an @return tag?
49 (commented on others PR)
Is this missing an @throws NullPointerException?
50 (commented on others PR)
Should field be fields?
51 (commented on others PR)
Should there be a blank line between description and parameters?
52 (commented on others PR)
Is this missing a param tag?
53 (commented on others PR)
Should there be a blank line between description and other tags?
54 (commented on others PR)
Is this class missing JavaDocs?
55 (commented on others PR)
Perhaps this method should have JavaDocs even though it's an overridden method?
Saw this in other files.
56 (commented on others PR)
Is this missing a param tag?
57 (commented on others PR)
Is this class missing JavaDocs?
58 (commented on others PR)
Should there be a blank line between description and @throws?
Saw this in other files.
59 (commented on others PR)
Perhaps the first letter of the @ tag description should be capitalized. That is,
@throws NullPointerException If the input is null.
Saw this in most other files.
60 (commented on others PR)
Is the parameter aliasName missing a description?
61 (commented on others PR)
Is this missing @param?
62 (commented on others PR)
Is this missing @param?
63 (commented on others PR)
Is this missing an @throws NullPointerException?
64 (commented on others PR)
Is this missing an @throws NullPointerException?
65 (commented on others PR)
Is this missing an @throws NullPointerException?
66 (commented on others PR)
Should field be fields?
67 (commented on others PR)
Should this be a instead of an?
68 (commented on others PR)
Oh, then maybe change it to The field must not be null.
69 (commented on others PR)
Should there be a space between the bottom-most import and the start of the class header?
70 (commented on others PR)
Is this missing JavaDocs?
71 (commented on others PR)
Consider adding JavaDocs to this because it is the key part of a predicate.
72 (commented on own PR)
Good catch, thanks.
73 (commented on own PR)
Hmm good point. An optional frame might suggest that a command being unsuccessful is the "happy path". My original intention was to convey the fact that unsuccessful commands will not be recorded in the command history, but I guess an activity diagram or a note in the sequence diagram might be more appropriate.
Thank you, I will consider this suggestion seriously for a future update.
74 (commented on own PR)
Thanks, added.
75 (commented on own PR)
Thanks, added.
76 (other comment)
Hi Colin, could you re-open this PR to the upstream master branch to follow the forking workflow?
77 (other comment)
As agreed in our team meeting, we will be splitting work by feature, not component.
78 (other comment)
As agreed in our team meeting, we will be splitting work by feature, not component.
79 (other comment)
As agreed in our team meeting, we will be splitting work by feature, not component.
80 (other comment)
Closed in #63
81 (other comment)
Closed because no longer relevant
82 (other comment)
Closed because no longer relevant
83 (other comment)
Closed because no longer relevant
84 (other comment)
We may want to break this up into at least 5 separate issues since each member is expected to update the DG. That way, each member can close the relevant issue when they are done with their part.
Further, I suggest we break up DG update issues by feature, rather than by team member because a DG update per feature seems like a more correctly-sized unit of work than a DG update per team member or one monolithic update consisting of everyone's updates.
85 (other comment)
I would like to discuss if the command history should also include failed commands. I think there is merit to mimic the same behaviour where the invalid command can be access via up and down arrow keys so that a Power User can edit the invalid command rather than retype it all.
If we do go down this path, I think a possible implementation is that each history entry will keep a field to keep the corresponding command used. Thus, if the field is null, it indicates an invalid command, otherwise it indicates a valid command.
Hmm, thanks for the suggestion. SunRez currently does not consume the user's input when a command is invalid, so a power user can already edit an invalid command easily.
86 (other comment)
Split into 5 separate issues that can be closed individually by each member.
87 (other comment)
Okay sure, thanks.
@nicholastanvis (64 comments)1 (commented on others PR)
bullet points starting with uppercase letter
2 (commented on others PR)
should we remove the parentheses?
3 (commented on others PR)
"confirm crucial commands with a confirmation message"
4 (commented on others PR)
2a1
5 (commented on others PR)
this backtick should be at the end of line
6 (commented on others PR)
missing triple dash
7 (commented on others PR)
missing full stop
8 (commented on others PR)
and Prompts
9 (commented on others PR)
format should be delete schedule
10 (commented on others PR)
find
11 (commented on others PR)
change back to Prompt: by module/day/week
12 (commented on others PR)
removing the 3 lines starting from this line fixes it
13 (commented on others PR)
for the tick
14 (commented on others PR)
double whitespace 👀
15 (commented on others PR)
task
16 (commented on others PR)
FindTaskCommand
17 (commented on others PR)
FindTaskCommand
18 (commented on others PR)
task
19 (commented on others PR)
tasks
20 (commented on others PR)
you might have forgot updateFilteredScheduleList, i'll merge my pr first
21 (commented on others PR)
might wanna change the usage because we are not deleting by index
22 (commented on others PR)
A
23 (commented on others PR)
the ellipsis at the end looks like it's asking for more parameters but in fact, the TAG parameter is supposed to be spread. i'm more towards explicitly defining [t/TAG] as 0 or more TAG arguments expected
24 (commented on others PR)
as an argument
25 (commented on others PR)
i do not see your activity diagram in developer guide at all. did you forget to include it?
26 (commented on others PR)
what is this for? as well as endTime
27 (commented on others PR)
kiv
28 (commented on others PR)
should we move these messages to commons.core.Messages? similar approach can be used for #94 #95
29 (commented on others PR)
should we add an assert statement here that throws if endDate.isBefore(startDate)
30 (commented on others PR)
um
31 (commented on others PR)
change to return equals(otherContact) maybe?
don't just check the name, there are people with the same names
32 (commented on others PR)
change to Contact's
33 (commented on others PR)
should we change to [A-Za-z][A-Za-z ]*?
names shouldn't be alphanumeric because underscores do not make valid names
34 (commented on others PR)
Contact
35 (commented on others PR)
Contact's
36 (commented on others PR)
should we do "\\+?\\d{3,}" :3
37 (commented on others PR)
contact
38 (commented on others PR)
editedContact
39 (commented on others PR)
editedContact, contact
40 (commented on others PR)
contact
41 (commented on others PR)
contact
42 (commented on others PR)
??? just use UniqueContactList
43 (commented on others PR)
contacts
44 (commented on others PR)
contacts, contacts
45 (commented on others PR)
change to UniqueContactList
46 (commented on others PR)
same as above
47 (commented on others PR)
contacts, contacts
48 (commented on others PR)
contact
49 (commented on others PR)
contacts
50 (commented on others PR)
what is this class name, change to NameContainsKeywordsPredicate
51 (commented on others PR)
check this file thoroughly and use an import statement to shorten this code
52 (commented on others PR)
this is not what i meant... IF YOU REMOVED isSameContact CHANGE UniqueContactList ACCORDINGLY
public boolean isSameContact(Contact otherContact) {
return equals(otherContact);
}
please change this method to the snippet above and revert UniqueContactList
53 (commented on others PR)
change variable name
54 (commented on others PR)
"Names should only contain alphabets, spaces and hyphens, and it should not be blank."
55 (commented on others PR)
refer to the comment in Contact.java
56 (commented on others PR)
keep this String, will resolve the conflict in #94 instead
57 (commented on others PR)
i was thinking of moving constants to commons.core.Messages, going to do the same for #94
58 (commented on others PR)
if this is reopened, revert this line. fixed in #100
59 (commented on others PR)
#100 should provide source.startTimestamp()
60 (commented on others PR)
let's use [day/week] so it's uniform with user guide
61 (commented on others PR)
we should check trimmedArgs first before we instantiate a ListEntryCommand. would going with something like this be better?
if (trimmedArgs.equals("day") || trimmedArgs.equals("week") || trimmedArgs.isEmpty()) {
return new ListEntryCommand(new ListEntryFormatPredicate(trimmedArgs));
} else {
throw new ParseException(
String.format(MESSAGE_INVALID_COMMAND_FORMAT, ListEntryCommand.MESSAGE_USAGE));
}
62 (commented on others PR)
thanks for the helper method, will revamp Entry#setTimestamp
63 (commented on others PR)
resolving, deleting the class will introduce breaking changes
64 (commented on others PR)
will fix in future prs
65 (commented on own PR)
will modify it as EntryTagContainsKeywordsPredicate
66 (other comment)
reopening. missed project description and credits to se-education
67 (other comment)
closed via #11
68 (other comment)
refactor UniqueTaskList to NonOverlappingTaskList
69 (other comment)
obsolete, refer to #80
70 (other comment)
the EntryNameContainsKeywordsPredicate is broken, will use the one in #97
71 (other comment)
permanently closed
@samleewy (59 comments)1 (commented on others PR)
It seems like this exception is relating to session, but i'm not sure if it should be named as IllegalArgumentException, since there's the default java exception IllegalArgumentException. Might be confusing in future. Perhaps we can further discuss this? @JonahhGohh
2 (commented on others PR)
🎉
3 (commented on others PR)
minor bug: find_session KEYWORD instead of find_student KEYWORD
4 (commented on others PR)
Perhaps we could consider the test case where it starts with 6/8/9, but has >8 digits in total, instead of this current one (or we could create a new one). Not sure how important it will be, but feels good to have!
5 (commented on others PR)
I believe should be k/120 instead of l/120, and t/18:00 instead of t/1800!
6 (commented on others PR)
Perhaps we could include an assertion for invalid days in month, for example 31 Apr is invalid since April only has 30 days, something similar to leap year check! (does the exception catch this actually?)
7 (commented on others PR)
This should evaluate to delete_session John Doe 1 but should be delete_session n/John Doe i/1
8 (commented on others PR)
HAHA this one abit ocd but perhaps make all the points not end with a dot for uniformity, otherwise lgtm!
9 (commented on others PR)
think you forgot to remove the comment right here
10 (commented on others PR)
Are these commented codes rough work? Might be better to remove.
11 (commented on others PR)
that's right!
12 (commented on others PR)
I'm not sure if the bracket filtered feels abit out of place. Maybe something like Listing students' emails based on current list might be better? Hahaha, maybe someone else can phrase it better!
13 (commented on others PR)
Nice catch on the missing delete_student!
14 (commented on others PR)
I think the header can be "Fees"?
15 (commented on others PR)
Then under action "Student fee by month", what do you think?
16 (commented on others PR)
I'm assuming the method is named parseStudyLevel to be uniform with the rest. However, for study level, it isn't exactly 'parsing', since it's String -> String. As compared to say email, where it's String -> Email.
Perhaps without changing method name, we could change the description to "Sanitize/Clean studyLevel input"? or something along that line. Don't think it's a big issue tbh, but what do y'all think?
Same goes for relationship as well!
17 (commented on others PR)
I think this might violate the 'explain WHAT and WHY, not HOW' @ textbook.
18 (commented on others PR)
Same comment as above (regarding WHAT and WHY not HOW).
19 (commented on others PR)
Honestly, i don't have a clear idea of how to phrase as well 🤣
One way is to remove comments, since it's pretty self-explanatory (as per textbook), maybe someone else has a better suggestion? @AY2021S2-CS2103T-T11-1/developers
20 (commented on others PR)
Minor change: Student instead of student
21 (commented on others PR)
Do you want to mention about how the filteredStudentList is updated as well?
22 (commented on others PR)
I think 'UI shows updated student list' comes before 'Logic saves the address book to the storage', according to the code:
commandResult = command.execute(model);
try {
storage.saveAddressBook(model.getAddressBook());
} catch (IOException ioe) {
throw new CommandException(FILE_OPS_ERROR_MESSAGE + ioe, ioe);
}
You can double check!
23 (commented on others PR)
How about a test case to consider when all/some parameters are null?
new Tuition(null, null, null, null)
24 (commented on others PR)
Perhaps {@code Session}?
25 (commented on others PR)
I think @yungweezy had Java 11 in code block in one of his PR, guess we gotta decide when we merge eventually?
26 (commented on others PR)
Should we change 'user' to 'tutor' instead? Might be more "relatable"
27 (commented on others PR)
Suggestion to rephrase: The Home tab gives tutors a quick overview of important matters. This includes their upcoming tuition lessons, as well as tuition fees receivable for the past 3 months.
28 (commented on others PR)
ok!
29 (commented on others PR)
Should help be placed below together with clear and exit instead?
30 (commented on others PR)
This is not related to your UG, but practicality wise, isn't it funny to have us accept same name but different cases? HAHA
31 (commented on others PR)
Not too sure if the 'Overlapping session will return an error' is necessary. But the 'takes care of overlapping session' also sounds very ambiguous (like we have some algo or something).
Perhaps phrase it in a way like 'TutorBuddy takes care of overlapping session for you by giving a gentle prompt, so you don't have to worry about it'
32 (commented on others PR)
I think don't need to quote 'sample' haha
33 (commented on others PR)
probably could rename it to boolean hasOccuredAtDate, since the name seems to clash with the method name.
34 (commented on others PR)
same for this as well, suggest to rename to hasOccuredAtTime
35 (commented on others PR)
Thanks for figuring this out! neat!!
36 (commented on others PR)
I'm assuming it's (firstInSpan.numOfDayTo(lastInSpan) / interval.getValue()) + 1. might be better to put brackets!
37 (commented on others PR)
recommend to rename to tuition1 and tuition2!
38 (commented on others PR)
Perhaps would be better if dd MMM YYYY, so it'll be 29 Mar 2021. more reader friendly!
39 (commented on others PR)
Seems like the sessionType is hard-coded for now. Perhaps create a variable in SessionCard.java for sessionType then hard code from there instead? To reduce confusion later on!
40 (commented on others PR)
So the time is a tab itself 🤣
This is not urgent, but perhaps we could shift the date/time to the extreme right? Would look nicer!
41 (commented on others PR)
Perhaps don't make it a tab! But yes can make an issue, not urgent!
42 (commented on others PR)
Might be better to flip points 2 and 3, so that it looks more 'uniform'
43 (commented on others PR)
Good to have a space between examples and bracket
44 (commented on others PR)
So, Examples (if applicable)
45 (commented on others PR)
Yeah same, think it's cuz it's within a >div>. Might need to replace clear with >code>clear>/code> (not too sure if it works)
46 (commented on others PR)
Same soln as above, worth a try. @JonahhGohh
47 (commented on others PR)
Riding onto this thread for another reason: should it be indices instead of indexes? HAHA
48 (commented on others PR)
maybe execute_correctMonthlyFee_success() would be better.
49 (commented on others PR)
I'm not sure if we should hardcode this, maybe run some codes to calculate Alice's fees for feb 2021 then concatenate it with the expectedResult?
I'm just afraid someone amends the TypicalStudent's sessions and this will screw up. What do you think?
50 (commented on others PR)
nice change!
51 (commented on others PR)
I think can remove 'filtered'?
"Returns an unmodifiable view of full list of students"
52 (commented on others PR)
hey @nowknowing, was the function outputting incorrect results prior to this?
53 (commented on others PR)
ah, you're referring to the case where it'll break the condition immediately if it doesn't meet !startAfter?
54 (commented on others PR)
This is more of aesthetics, but would be great if we can do sth like:
sessionType.setStyle("-fx-background-color: >color>");
and give different colors for R & I.
Then, add padding for sessionType label in the fxml.
Just some aesthetic improvements, not necessary if too rush!
55 (commented on others PR)
Would suggest to abstract:
populateTuitionList(studentList, tuitionList);
sortByDate(tuitionList);
populateUpcomingTuitionListView(tuitionList);
into another function. seems like you're repeating these 3 lines both outside and inside the listener.
56 (commented on others PR)
might want to consider using tuitionList.sorted(...) instead. Might be cleaner, just like how I did it in calendar. but this is fine as well!
57 (commented on others PR)
If this function checks for whether it's within today, tomorrow and the following day, do we need to pass in the parameters today and dayAfterTomorrow? cuz probably can use LocalDateTime.now() and LocalDateTime.now().plusDays(2).
Unless this is generalised to a "check within data range" kinda function.
58 (commented on others PR)
Unimportant feature: maybe can add padding as mentioned above.
59 (commented on others PR)
right... i see where you're coming from. i doubt there's an issue with code quality, just that i personally feel that it's abit odd to be named isWithinThreeDaysRange and we have to indicate today+2days (dayAfterTomorrow) date as well haha
if you're ok with it then feel free to merge!
on second thought: MUST the dayAfterTomorrow be today+2days? will it break if another dev inputs a random date? maybe assertion will be good here then.
60 (commented on own PR)
The chunk (from line 114 to 138) is commented out using HTML >!-- --> tags! So should be irrelevant for now.
61 (commented on own PR)
Yup, I agree. something we can keep in consideration beyond v1.2.
62 (commented on own PR)
Oh and as for the comment out, the chunk (from line 114 to 138) is commented out using HTML >!-- --> tags! So should be irrelevant for now.
63 (commented on own PR)
Commenting out in the middle of list items creates a bit of a weird gap in between. I'll take your suggestion and comment it out at the bottom, so we can restore it easier next time!
64 (commented on own PR)
I think can imagine the listener as something that's running in the "background" and always monitoring the ObservableList>Student>, so whenever there's any changes to the list of students, the code within the block will be invoked. As for the change.next(), if there are multiple changes made, they're represented as a 'separate change' (list of changes), so change.next() loops through it (might not be 100% correct in this part).
The ListView>Session> is actually bound to the ObservableList>Session> sessionList, so whenever there's a change in the sessionList, which is shown in this block of code you commented, the ListView will update as well.
(might not be 100% correct)
65 (commented on own PR)
Amended in next commit!
66 (commented on own PR)
Amended in next commit!
67 (commented on own PR)
Amended in next commit!
68 (commented on own PR)
Amended in next commit!
69 (commented on own PR)
Amended in next commit!
70 (commented on own PR)
I think that's how it's supposed to be, just like in JsonAdaptedStudent
71 (commented on own PR)
Will be done in 1.3!
72 (commented on own PR)
No sir, it should be students.deleteSession(student, sessionIndex);
73 (commented on own PR)
Amended in next commit!
74 (commented on own PR)
Amended in next commit!
75 (commented on own PR)
It's activity and sequence diagram! hahaha
76 (commented on own PR)
Oh yes, i also found the indentation weird as well. Will make the change, thanks!!
77 (commented on own PR)
Whoops was copied wholesale 😂 will make the change, thanks!
78 (commented on own PR)
Ok thanks!!
79 (commented on own PR)
ok got it! will make the changes
80 (commented on own PR)
actually used cmpSessionDate to shorten code 😆
will make the change, for both cmpSessionDate and a!
81 (commented on own PR)
got it!
82 (commented on own PR)
got it!
83 (commented on own PR)
got it!
84 (other comment)
looks good to me as well, nice catch, will proceed to merge.
85 (other comment)
Made changes mentioned by @yungweezy @enhao25, merged! 🎉
86 (other comment)
@samleewy I think the comments change and parse method name change, I'll create a new issue so that we can discuss. For now, maybe you can approve this first to fix the trim date bug?
sure!
87 (other comment)
LGTM!
What do you having this condition as "valid command input format" instead? I feel like "command exist" is not very clear 😅
@JonahhGohh ok will change, thanks!
88 (other comment)
Not a code review, but perhaps can link it to your Issue #84 to close.
89 (other comment)
Tom was added first with:
start time: 12:00
duration: 1hour
Samuel Lee was added second with:
start time: 11:00
duration: 2hours
Should conflict, but didn't. KIV.
90 (other comment)
Thanks for the hard work on the Calendar feature. The UI looks amazing and the feature seems to be working well. Can't seem to find any bugs.
One thing to consider is that find_student also filters the calendar view. We might need to mention this in our UG also.
OH RIGHT. the find_student will filter the calendar view as well.... Doesn't feel ideal 😂 Will see if I'm able to do it separate from it.
91 (other comment)
Thanks for the hard work on the Calendar feature. The UI looks amazing and the feature seems to be working well. Can't seem to find any bugs.
One thing to consider is that find_student also filters the calendar view. We might need to mention this in our UG also.
OH RIGHT. the
find_studentwill filter the calendar view as well.... Doesn't feel ideal 😂 Will see if I'm able to do it separate from it.
I added a PR for this #148. I saw that u did something as well ah. But then I just created a method for it so that everyone can use it ah.
@enhao25
ok! will change to your method after the PR goes thru. thanks
92 (other comment)
Github doesn't allow me to add comment on unchanged lines 😦 but i noticed that you passed in
logicinto yourCalendarViewconstructor.
Since you are only using logic to get the full student list, how about using the
ObservableList>Student>parameter in the constructor and usinglogic.getAddressBook().getStudentList()inMainWindow.
This also standardizes with the other code in the
fillInnerParts()method.
@JonahhGohh yep! I made this change in the latest commit together with @enhao25's getFullStudentList(). If everything's ok then i'll merge!
93 (other comment)
LGTM! Tried testing the calendar feature on my computer and works nicely! Codebase looks good also.
I think this issue was brought out recently in the group chat regarding overlapping sessions. But I think it exist as an issue already and is not part of calendar.
Hence, no issue and approved!
thanks!
@JayChenYJ (58 comments)1 (commented on others PR)
Perhaps standadise it to ITEM_NAME.
2 (commented on others PR)
Same for here 😃
3 (commented on others PR)
Same for here 😃
4 (commented on others PR)
Our list takes in an optional parameter, so may consider removing it from this line.
5 (commented on others PR)
our list should be able to in an optional field, location.
6 (commented on others PR)
Should consider changing edits to updates 😃
7 (commented on others PR)
Should be deleting an item instead 😃
8 (commented on others PR)
Check google docs for delete method for StoreMando 😃
9 (commented on others PR)
One suggestion I have for these JSON files is that maybe we should rearrange the sequence to match our display sequence to make things more neat and tidy 😃 so instead of the current name, quantity, exdate, location, we put name followed by location and so on based on our current display.
10 (commented on others PR)
Some variable changes are still seen here and there
11 (commented on others PR)
For this part just let Fazil know to change this to standardised locations, because this one he may overlook thinking that it's correct cause Apple Banana etc are what we using for item names.
12 (commented on others PR)
For this when it is showing all items will it also work as normal?
13 (commented on others PR)
It May be too technical for a user guide
14 (commented on others PR)
Perhaps its better to say 'Expiry date of an item is optional'
15 (commented on others PR)
Why is there an additional catch NullPointerException?
16 (commented on others PR)
understand that for this file the sequence in which what is placed first does not matter, but for readability and consistency of our code base we should perhaps standardise it, following the google docs sequence
17 (commented on others PR)
I think "Quantity should only contain numbers..." will suffice, can remove the "numbers" after Quantity
18 (commented on others PR)
This may be a violation of Law of Demeter, cause browserutil calls a method that calls helpwindow's string. Maybe can consider shifting the USERGUIDE_URL to BrowserUtil instead 😃
19 (commented on others PR)
Instead of calling 2 booleans, maybe inside BrowserUtil class create a boolean to check for these 2 booleans, since at this class we don't have to know the details. Maybe can create a boolean called canOpenBrowser 😃
20 (commented on others PR)
Agree with this, but if its functional we can leave this to v1.3 as well. 😃
21 (commented on others PR)
Personally I will prefer trimmedArgs = trim()
Then in the condition, we use equals ignore case instead.
22 (commented on others PR)
What's the set of names we following from now on? For the original ab3 it was ALICE, BENSON, CARL, DANIEL, ELLE, FIONA, GEORGE. What's the pattern for ours?
23 (commented on others PR)
Agree with kums!
24 (commented on others PR)
Agree with Fazil!
25 (commented on others PR)
I feel that this shouldn't be an exception condition because we should instead just ignore whatever that's not the first arg. So reminder 6 haha should just take it as reminder 6. on the other hand reminder haha 6 shouldn't work but it has been considered in ur try catch method below.
26 (commented on others PR)
Whats the reason for parsing it as long instead of int?
27 (commented on others PR)
With my suggestion below, this will become unnecessary
28 (commented on others PR)
for this whole parsing right, perhaps you may wanna think about changing it to a prefix kinda thing. Say reminder d/3 reminder w/2, with that you will be able to use preambles and also prefix isPresent to do most of the checks here and I can foresee the code to be neater 😃
29 (commented on others PR)
how will the >a name = "delete">>/a> look like in the user guide page?
30 (commented on others PR)
perhaps change to 'NUMBER' instead, because in our user guide only command words are small letters in format I think 😃
31 (commented on others PR)
will 1 day and 1 week work? or even 1 must be days and weeks?
if 1day and 1week work then that's the best. Else here's my suggestion:
change the implementation such that 1 day and 1 week will work.
make it extra clear in the user guide (1 more sentence behind it) to emphasise that day and week will not work. 😃
32 (commented on others PR)
There will be a need to update this part of the user guide because now there is quantity asc and quantity desc 😃
33 (commented on others PR)
also this, it should be expirydate, emphasise to the users too that it is case insensitive. 😃
34 (commented on others PR)
There will be a need to look into this section to double-check, examples will be reminder and sort. 😃
35 (commented on others PR)
Can we add one example for weeks as well? 😃
36 (commented on others PR)
I think u just need the first line to be in if else statement, the rest should be outside as one right? 😃
37 (commented on others PR)
Maybe instead change it to 3 positive path conditions in if elseif, throw in else. 😃
38 (commented on others PR)
maybe change from 'remember items' to 'keep track of items' 😃
39 (commented on others PR)
Should it be 'make the most of StoreMando' or 'make the most out of StoreMando'
40 (commented on others PR)
What will >a name="start">>/a> show in User Guide page?
41 (commented on others PR)
Will this hyperlink still work after u added '3.' for 'features' below?
42 (commented on others PR)
Can we make this example more legit, perhaps change to l/kitchen cupboard 1(somewhere more normal) ... e/2021-04-01(a date that is more updated as of our user guide edited date)
43 (commented on others PR)
Is there any part mentioning that '[]' equals to optional? because even though tag has '...', in edit for example most of our parameters only have '[]' 😃
44 (commented on others PR)
I think this info about the index being positive is not required because it has been stated very clearly in the sentence before this that 'The index refers to the index number shown in the displayed item list.' 😃
45 (commented on others PR)
same issue with the previous examples, which is likely to be the same for the rest of the examples. Please look into this! Thanks! 😃
46 (commented on others PR)
Same reasoning on this just like the previous comment. 😃
47 (commented on others PR)
Why is this not bold anymore? How will it look like in the user guide page?
48 (commented on others PR)
u did the assertion then here no need the if alr right 😃
49 (commented on others PR)
I think SortQuantityCommand shouldn't be taking in a boolean 😃
1 suggestion I can think of is to create 2 separate classes handling asc and desc. I think there is a more elegant way though 😃
50 (commented on others PR)
Can remove this assert because now the number of days can take in any number 😃
51 (commented on others PR)
maybe consider declare 2 final long at the start, so next time if we want to change the day can be easier, currently is like magic number 😃
52 (commented on others PR)
I think better to put like private static final long EXPIRED_NUM = 0 etc 😃
53 (commented on others PR)
are the lines required for proper display? oTHER 💡 etc got such lines?
54 (commented on others PR)
If you are putting a line break then i suggest you give it #### for the sub headers 😃
55 (commented on others PR)
This one no need already. Can change to
TIME_UNIT must be either days or weeks.
day or week accepted when number is in the range of [-1, 0, 1]
56 (commented on others PR)
This example abit too specific, by the time people read it it won't make sense already
57 (commented on others PR)
I think some of these test cases are too repetitive, I understand that it is to test for boundaries but i don't think this many test cases are needed. Maybe just boundary for 1/2 months etc. Same applies to other checks in this file 😃
58 (commented on others PR)
I think Prof Damith mentioned something about there's no need to check for different types because it simply will not be the case. I understand that in original AB3 they had some tests checking types but I think we can omit all of such test cases. 😃
59 (commented on own PR)
Fixed 😃
60 (commented on own PR)
Resolved. 😃
61 (commented on own PR)
Nope it was not fine, thanks for spotting!
62 (commented on own PR)
Yup I will remove this file now. 😃
63 (commented on own PR)
Better Model class puml is not in use as of now. 😃
64 (commented on own PR)
It looks like this now, the hidden arrows wont be displayed.
65 (commented on own PR)
Thanks!
66 (commented on own PR)
This will need to look into it further in v1.3b, we will take note of this! thanks!
67 (commented on own PR)
Yup thanks Fazil!
68 (commented on own PR)
Understand, will make changes on that! Thanks!
69 (commented on own PR)
Will add more test 😃
70 (commented on own PR)
Alright I will try 😃
71 (commented on own PR)
I think this is fine because I'm calling the itemlist in model itself and not somewhere else right 😃
72 (commented on own PR)
no, it basically takes in all the words in the args, so say " 3 day ", it will become "3" and "days" 😃
@enhao25 (57 comments)1 (commented on others PR)
Actually just thinking what would happen if we put the time as 23:592. This is because when trying out the iP, I noticed that one of those that I am reviewing failed this test, so you could include 1 more test with this value to ensure that adding extra values to the timing will not cause any unexpected behavior ah.
2 (commented on others PR)
Yeap! I think that the test case should fail with these values.
3 (commented on others PR)
Hmmmm honestly I tot that changing the values for amy bee here will will affect places like the CommandTestUtil.java as well and fails the test case. But seems like it passes the test case. Seems like they are not linked then. But just in case next time there is some error for this, we might need to check back ah.
4 (commented on others PR)
Should we comment out find_session here instead of deleting them?
5 (commented on others PR)
Ohya actually is find_session part of v1.2? Cos now that I think about it, its quite weird for find_session to include the Index. Like it wouldn't make sense for me to look through the whole list of session and try to get the individual index and then run find_session again, cos the information we give from the session list and find_session would be exactly the same. It would make more sense for it to be just find_session s/STUDENT_NAME. But if this is not under v1.2, I think we should comment this out first before we discuss again?
6 (commented on others PR)
As per the above, this seems to follow the find_session s/STUDENT_NAME instead ah, should we comment this out first?
7 (commented on others PR)
Ah ok! Didn't see that the comment header start at line 114.
8 (commented on others PR)
Great!
9 (commented on others PR)
Hi, just want to check as the previous line ": Deletes the student identified by the index number used in the displayed student list.\n" already has an \n, does having an additional \nParameters here cause anything weird on the UI? Might be better to just keep one.
10 (commented on others PR)
Hi, just checking if this is something extra that you did that isn't really related to the UI. Can I check if the purpose of this code is to check if the equals method works as expected?
11 (commented on others PR)
Hmmm using student instead of s, might be better in this case
12 (commented on others PR)
Hmmm is these commented out withsession intended?
13 (commented on others PR)
Looks good! Just wondering if there could be comments here similar to ModelManagerTest.java equals method, to better allow the others reading this code to understand the test cases here better.
14 (commented on others PR)
Hi, just wondering, since the AddressBookParser is in `` in the next line, we could possibility AddressBookParser here for consistency as well.
15 (commented on others PR)
Haha based on what jonah said, actually why you changed also ah. I tot its part of Logic, isit because you did the delete_student command previously?
16 (commented on others PR)
Hi, perhaps you could copy the diagram over to a folder with your name instead and restore the original file ah.
17 (commented on others PR)
Hmmm I think line 154 to 155 and line 157 to 158 are duplicates ah.
18 (commented on others PR)
O.o damnnn u did both. Haha ok sorry. Let me go approve ah
19 (commented on others PR)
Actually I think this part is abit confusing for me, aliceInTuition when calling new Tuition() has a sessionIndex of 2, however, we assertNotEquals that getSessionIndex() is 2, isit because of the difference between the zero index and one index?
20 (commented on others PR)
Same comment as the getSessionIndex() above.
21 (commented on others PR)
I think there is additional space on to LogicManager, but small problem ah.
22 (commented on others PR)
Actually you could include ../style.puml instead, so you don't have to make a new copy of the style.puml in your folder ah.
23 (commented on others PR)
Only one comment, I was thinking the indentation for the addSession(withSession previously) was abit weird and should have the same lvl of indentation with withStudyLevel instead. Do you think it would be better if we did that?
24 (commented on others PR)
Actually outside of scope, but this comment here seems abit unnecessary with ////, I think we could just use // instead, so that it won't be flagged as a "bug" during PE dry run.
25 (commented on others PR)
Hi, was just wondering if the ArchitectureSequenceDiagram has been changed to match any command, if yes, do put it into a folder with ur name and rename the image src accordingly! Thanks!
26 (commented on others PR)
Actually I think we do not have to edit the tutorial codes ah. It probably shows up here cos of refactoring.
27 (commented on others PR)
Yeah, I think as per the tutorial yst, having a class diagram of a single class might not add value in this case.
28 (commented on others PR)
Hmmmm actually using TAG in this case might not be intuitive as we do not have a tag parameter in our entire application. If we are to include this here, maybe a different parameter and including the edit_student in the UG would then be more useful.
29 (commented on others PR)
Using KEYWORDS during find_student as the example might be better than using tags here.
30 (commented on others PR)
Looks good, however, do remember to add this command over to the TOC and the command summary at the end of the page for consistency.
31 (commented on others PR)
Hi, just wondering, is "to the TutorBuddy" quite werid, I tink its copied over from single session also. I think changing over to "to TutorBuddy" removing "the" would be better. What do you think?
32 (commented on others PR)
Hmmm maybe using "class" here might not be suitable as a class is usually associated with a group 1-many tuition. Just putting as "Or efficient way to calculate your incomes?" might be better.
33 (commented on others PR)
Hi shion! I think you have updated the class at some other places. I think updating it here under class income will be good as well. (E.g. Lesson incomes instead class incomes)
34 (commented on others PR)
Yo actually what is this for ah?
35 (commented on others PR)
Hi, understand the the testing is still a work in progress, but I think it could be better if we didn't use System.out.println() when we are merging to master. Using assertions might be better.
36 (commented on others PR)
LGTM. But was thinking if we can be more explicit that the interval is in terms of the number of days.
37 (commented on others PR)
Hi was just wondering what could does >p> mean. Isit a typo?
38 (commented on others PR)
Hi, just checking, for this implementation, we run super(session) to create a standalone session out, but then it doesn't seem to keep a reference to the created session anymore. Can I check if that is the intended effect?
39 (commented on others PR)
Hmmmm already, actually didn't use super often so not sure how it would work out. We could keep this in mind and when the rest of us work on features that uses recurring session, see if we are able to perform all the actions we want, even w/o keeping a reference to it ba.
40 (commented on others PR)
Actually not sure if other groups will nitpick this, but we could give s1 and s2 a more meaningful name such as sessionDate1 and sessionDate2. Will be longer, but at least we prevent other group from nitpicking these small bugs ah.
41 (commented on others PR)
Hi, maybe we could add a //TODO: tag here, so that we would remember to come back here in the near future and work on this.
42 (commented on others PR)
Also I am just wondering if there could be a way (Probably through a command) to add a recurring session into to application, so that the reviewers can checkout and run the PR to perform manual testing as well, to better understand your implementation. Not sure if you want to work on that first before we reveal and approve this to ensure that the implementation passes some light testing. If not it might be hard for me and jonah to test if our feature works if we couldn't add recurring session inside to the addressbook to test.
43 (commented on others PR)
LGTM, I think "40" is missing a space, to be "40 "
44 (commented on others PR)
Maybe you would want to pull upstream first and merge inside, I believe that choon wei added a functionally that previously adding session that clashes. (E.g. If a session that starts on 2020-01-01 12.00 that last for 120mins, we can't create another session that is between 2020-01-01 12.00 to 2020-01-01 13.59) Although, with recurring session, this is much harder to achieve, because we need to take into consideration from the start to end date, if adding this rec_session will clash with future individual sessions as well. Not sure if you want to push the 2nd part into a separate issue as it seems like quite a big implementation.
45 (commented on others PR)
Ohya one of the possible issue is that I think the storage has no way of identifying now whether a session is a recurring session or a standalone session. I tried creating the recurring session, close the app and open it again, and the recurring session becomes a standalone session now. Might need to take the storage into consideration, either in this iteration, or as a separate issue.
46 (commented on others PR)
Hi thanks for the hard work. One of the bugs I found was that if I were to put a value where the end date and start date doesn't match, instead of showing an error message, an exception occurs. I think for this, it would be better to show some form of error message to the user instead.
47 (commented on others PR)
Hi, so sorry, but I am not sure where the error is.
However, if you run the command:
add_rec_session n/Alex Yeoh d/2020-03-03 t/12:00 k/90 s/Math f/40 b/7 e/2020-03-17
then close the application, open the application again.
Run the command:
delete_session n/Alex Yeoh i/>number of the recurring session>
You will notice that the output will be "Deleted Session: Date: 2020-03-03; Time: 12:00; Duration: 90; Subject: Math; Fee: 40.0" instead of "Deleted Recurring Session: Date: 2020-03-03; Time: 12:00; Duration: 90; Subject: Math; Fee: 40.0; Interval: 7; Last Date: 2020-03-17".
Hence, the although the storage is storing the interval and last session value inside the json file, I think when the system reads from the storage, it creates a session instead of a recurring session. Might need to look into that.
48 (commented on others PR)
Just some minor consistency issue, this could end with a . as per your other javadoc sentences. Using populates instead of populate here might be better according to the java coding standard.
49 (commented on others PR)
Hi, was just thinking that maybe displaying date and then time could be better in this case, just a suggestion ah as it feels more intuitive for me, although is debatable.
50 (commented on others PR)
Hi, was just thinking that maybe capitalizing the first letter for each of the sub section would be better. "the result.." to change to "The result". This is the same for 1 and 2 as well.
51 (commented on others PR)
Nice! Was thinking if it might be good to use >div style="page-break-after: always;">>/div> as stated in https://se-education.org/guides/tutorials/savingPdf.html for us to ensure that the introduction section always starts at a new page. Might be good to include this at before the start of a key section (E.g. Before Intro, Commands and Command Summary)
52 (commented on others PR)
Abit OCD, but I think most of the examples don't end with ".", might be better to remove it as well.
53 (commented on others PR)
Just thinking that edit_student before delete_student might be a better flow. Since a user can add a student, edit that student and then proceed to remove it after.
54 (commented on others PR)
Just wondering if writing the key features in point form would be better to catch the attention of the user.
55 (commented on others PR)
Actually abit OCD, but as per the java coding standard for javaDocs, maybe adding a full stop to all of the javaDoc comments might be more consistent.
56 (commented on others PR)
Hi, was just wondering is using sessionDateComparator instead of cmpSessionDate might be more meaningful.
Replacing "a" for the "a -> a.." to something more meaningful will be helpful for the developers as well.
57 (commented on others PR)
Maybe can use "Must" instead of "must" for consistency.
58 (commented on own PR)
Ok ah I will change the values in the file back to the original code, I have no idea why this file is in our directory also.
59 (commented on own PR)
Updated.
60 (commented on own PR)
Updated.
61 (commented on own PR)
Updated.
62 (commented on own PR)
Waaaa nice catch man! Updated it accordingly already!
63 (commented on own PR)
Ok good catch! Have updated the test to include these 3 cases.
64 (commented on own PR)
Haha alright! Updated
65 (commented on own PR)
Haha LMAO, but I think its fine tou, it allows the reader to understand that its filtered, and can be the full list also.
66 (commented on own PR)
Alright, updated to Listing students' emails based on current list instead and also updated the TOC
67 (commented on own PR)
Haha yeah I tot of before, but then I think at most there will only be 2 commands, one to get monthly fee for a particular month, one to get past 3 months fee. So not sure if it should be a section by itself. Although I think doesn't hurt to change ba. I will make the changes first then.
68 (commented on own PR)
Actually not sure if its ambiguous, I think if we really want to be specific "Student fee for a particular month and year" would be more accurate. Will update to this version first.
69 (commented on own PR)
Nice catch!
70 (commented on own PR)
Took the comment and added the information
71 (commented on own PR)
Nice catch! Updated as required
72 (commented on own PR)
Hmmm ok, seems like ur use the filteredStudentList in your explanation also, so I included them as well ah.
73 (commented on own PR)
Ah ok! Seems logically, updated it already.
74 (commented on own PR)
Ok good suggestion, the only common place for both code base is on model. Hence, I have abstracted out the get fees code over to model. Do have a look, the output should still be the same. Thank you!
75 (commented on own PR)
Ahhh right! I have changed it to 3_month_fees instead.
76 (commented on own PR)
Alright! Change from that to "Shows the totalled fees per month, for this month + previous 2 months" instead.
77 (commented on own PR)
Yeap should be correct. I copied over from https://github.com/nus-cs2103-AY2021S2/tp/blob/master/docs/UserGuide.md. On github, it shows as per the picture as well, however when its in the webpage, it should looks as what we expected.
78 (commented on own PR)
Updated.
79 (commented on own PR)
Hmmmm I followed https://nus-cs2103-ay2021s2.github.io/tp/UserGuide.html ah. I think the reason why they did that is that it is more sequential ah. A person who starts must know how to "get help" before even starting to learn about the commands. After trying out all the commands, he / she can then clear the application and then "start" actually using their own data for the application. Thereafter they can exit the application. This seems to be quite a logic flow. What do you think?
80 (commented on own PR)
Haha yeah ah. But I think if we want to change, we need to update it at alot of places though. So I put it here as a "feature", so people can't dispute with us, saying its a bug ah.
81 (commented on own PR)
Updated
82 (commented on own PR)
Yeap sounds better! Have updated.
83 (commented on own PR)
Anw if you want, we could create an issue, then if we have time then we can work on that ah. If not then we will just go along with this?
84 (commented on own PR)
Haha ok sure! Updated.
85 (commented on own PR)
Hmmm ok sure! I have made the amendments, feels like I am doing a calculation outside, and then a calculation inside the command and comparing them. But ok ah, don't think it will ever fail now.
86 (commented on own PR)
Haha right! Thanks thanks! Have updated in the latest commit!
87 (commented on own PR)
Haha right! Will remove it! Thanks thanks!
88 (commented on own PR)
Ah right! It will make the code looks nicer ah. Have done so in the latest commit! Thanks!
89 (other comment)
LGTM.
The Student Commands need to be updated after the addition of the Tuition class #40
Ok great! Should we merge this first? Since we are doing this in phrases, I think it makes sense that we merged inside after a functionality is done, compared to merging it when tuition + session + student is done together. I believe choon wei would have to reference this changes to work on the tuition class as well. Delaying the merging could mean that there will be alot of conflicts when we ultimately try to combine everything together.
90 (other comment)
LGTM!
So, this will only be an issue if the user is using a 32-bit system?
Yes I did a rough search and it seems that it is possible that 32-bit system running java might have the 2038 error. Hence I think setting an upper limit to >=2037 would be a good compromise.
91 (other comment)
Tested it and works well!
I like how you compared the dateTime with the compareTo() method, clean af haha.
Regarding the 3 month command, I was thinking of using it for the Home fee section. So not too sure if we need a command for it.
Haha I agree ah! For the 3 month command thingy, I was also thinking that we might not need the command. So haven't added it to the UG yet. Probably can keep the command for testing purposes, and remove it after the UI that uses the 3 month function is done.
92 (other comment)
Ok! I think it shouldn't affect much, so just leaving it as fees should be fine.
93 (other comment)
closes #81
94 (other comment)
Done from https://github.com/AY2021S2-CS2103T-T11-1/tp/pull/118
95 (other comment)
Thanks for the hard work on the Calendar feature. The UI looks amazing and the feature seems to be working well. Can't seem to find any bugs.
One thing to consider is that find_student also filters the calendar view. We might need to mention this in our UG also.
OH RIGHT. the
find_studentwill filter the calendar view as well.... Doesn't feel ideal 😂 Will see if I'm able to do it separate from it.
I added a PR for this #148. I saw that u did something as well ah. But then I just created a method for it so that everyone can use it ah.
@daniellau88 (46 comments)1 (commented on others PR)
Do remove the trailing whitespaces in order to pass the build checks
2 (commented on others PR)
Is this needed?
3 (commented on others PR)
I think would be nice to remove the comma to standardize
4 (commented on others PR)
Additionally, can you help to remove Line 8 as well (I think not relevant)
5 (commented on others PR)
Sozz, i realized the bolding looks a bit weird, would be good to keep the bolding within the same sentence.
6 (commented on others PR)
For this portion, I think would be better to use the one in @weixue123 's branch, so might need to merge it in first.
7 (commented on others PR)
Would be nice to have spacing between CHIM and the full stop
8 (commented on others PR)
Are we keeping this portion? Can refer below for the modified command in @weixue123 's repo
9 (commented on others PR)
Use the static method getCheeseType instead of the constructor (wanted to make the CheeseType a bit Enum like so we can also use == for comparison)
10 (commented on others PR)
Add whitespace
11 (commented on others PR)
Would be good to leave it as private and use the static method
12 (commented on others PR)
Do specify the type of each date, currently it doesn't show what each date represents
13 (commented on others PR)
Same for order
14 (commented on others PR)
Any reason to prefer this over null?
15 (commented on others PR)
Is it possible to increase the padding? The cards seems a bit too packed
16 (commented on others PR)
Would it be possible to use enums instead?
17 (commented on others PR)
add assertion error here
18 (commented on others PR)
Remove debug statements
19 (commented on others PR)
Possible to extend DeleteCommand to do more. for e.g. help to do the basic checkings such as index out of bounds and so on. If not enough time, its fine
20 (commented on others PR)
(must be a valid phone number)?
21 (commented on others PR)
use .equals instead
22 (commented on others PR)
would be good to do new Phone(customerToDelete.getPhone().value) to ensure that it is comparing by value and not just by reference
23 (commented on others PR)
Would you be double calling the method (because you call it in Delete___Command.java as well). Would suggest that you call it from outside instead of here.
Possible use case is, in the future if we allow deletion of customer with all of the customer's order, the panel should only change to the customer panel and not the order panel
24 (commented on others PR)
Just a suggestion (but up to you), you can consider using "Assigned" and "Not Assigned" instead
25 (commented on others PR)
use .map(x -> x.toString()).orElse("-") so that it does not throw null pointer exception
sorry forgot to update this in properly in previous commit
26 (commented on others PR)
Additionally, do add isAssigned to .equals as well.
27 (commented on others PR)
Do the cheeses need to be updated to have the isAssigned attribute?
28 (commented on others PR)
yeap something like that
29 (commented on others PR)
seems like a static method because it doesnt seem directly related to the object
30 (commented on others PR)
Would be good to set the panels inside the commands instead.
Was thinking in the future, if we for some reason modify a cheese's ID, and have to update the order too, then the view will be changed to the order panel (instead of the cheese panel)
31 (commented on others PR)
The logic is good 😃 possibly can do 2 things
Sort by maturity date too (to ensure that the assigned cheeses are matured)
Can just use a counter to count the cheeses instead of using decreaseQuantity(), seems a bit sketchy haha
I think the setCheese should be done else where maybe in the command (using model.setCheese()). The getUnassignedCheeses should only get the cheeses without updating anything yet
32 (commented on others PR)
Additional whitespace here
33 (commented on others PR)
I'm not sure if it would be benefitial for us to set quantity's value to private (because it is already final so we can't rly change it anyways). But if you do have a purpose for it, then I'm alright with it
34 (commented on others PR)
Hmm, curious, does equals on the hashset not work?
35 (commented on others PR)
I think I found out why (my part also affected by this), have to make sure that all the ids have the same hash. Will be updating in my branch
36 (commented on others PR)
Was thinking that CheeseId should not be doing things for the sake of the stub (i.e. not know of the existence of the stub). Can just specify that it returns the next Id?
37 (commented on others PR)
Add newline before Example
38 (commented on others PR)
Same here
39 (commented on others PR)
Do update the toString method for cheese (now showing optional.empty)
40 (commented on others PR)
Currently, there is one issue with this. Steps to replicate:
Use find command to Find Customer B
Delete Customer A
The customer phone number provided is invalid.
I would suggest to use the getCustomerWithPhone to find the customer instead, filteredCustomerList is a bit unreliable
41 (commented on others PR)
Instead of doing this, would it be possible to have a method, e.g. getOrdersForCustomer so that you don't have to change the filter all the time? I'm afraid similar bugs as the issue mentioned before may appear
42 (commented on others PR)
Same as the comment in #37, don't think that we should change the UI portion just to delete the cheeses (although functionaility-wise it is exactly the same, just the organization is a bit different)
43 (commented on others PR)
Would suggest to use the getCustomerWithPhone method in AddressBook instead of filtering the whole list
44 (commented on others PR)
Do resolve conflicts
45 (commented on others PR)
Same here
46 (commented on others PR)
this not needed here? seems like a repeat in OrderPhonePredicate
47 (commented on own PR)
Will bring up a proposal for this in the meeting
48 (commented on own PR)
My bad, the class should be used in Order, will add in in next commit
49 (commented on own PR)
3 Things
This portion of code is to test the EditPersonDescriptor (which is not a part of the model, but only used inside Commands, hence this should be in the right place
Regarding invalid dates, will add a few in the Dates class
Regarding invalid cheese types, currently there is no way for a cheese to be of an invalid type (because it just needs a name), unless we check for empty String
50 (commented on own PR)
Would be nice to standardize but might not be necessary (will have a lot of existing codes to update)
Will bring it up in meeting tmr
51 (commented on own PR)
I think would be good if it is the 1st case (less bugs when they smoke test)
52 (commented on own PR)
Which would you suggest to drop? If we want, we can just keep expiry and manufacture date (then I can add one more case in the AddressBook to ensure that the Cheese's manufacture date must be after the order's order date)
53 (commented on own PR)
I think this might cause some trouble on our side cause imagine if Order shows all the cheeses that are assigned to it (and also cause order needs to check that the cheese is of the same type).
I think, we can possibly disallow cheese deletion if the cheese has been assigned? (cause I think delete cascading will be bad for this)
54 (commented on own PR)
Will discuss on Saturday
55 (other comment)
The AboutUs image is not working... I think you would need to rename it to laurenlhy.png (currently its named laurenlhy.png.JPG)
56 (other comment)
Hi, you can check out the branch telegram-github-notifier on the master repository. It seems that the build isn't working there as well.
Forbidden: bot can't send messages to bots
57 (other comment)
Actually do you want to squash some of your commits, before merging. But other than that, everything seems fine.
Yea, I think would be good to squash to about 3 commits
58 (other comment)
I rebased the branch, gonna merge it in soon
59 (other comment)
Closed in favour of #20
60 (other comment)
Do remember to modify your code to support the toggling of views once #20 is merged in
61 (other comment)
There is one class of ModelStub with no useful methods, and the rest of variations are extending from it and overiding methods important for testing. We could make it abstract though. What else do you think we can do. The idea is we have two kind of test suites: 1 with using the actual ModelManager and 1 using just the stubs.
I probably can't think of a better way to do it, but I'm afraid in the future it might get a bit messy because of the so many variations
@nighoggDatatype (45 comments)1 (commented on others PR)
Please add "by their name". Your sentence is hanging right now
2 (commented on others PR)
literal "abc" should be the constant NAME_FIRST_PERSON
3 (commented on others PR)
please put this in a final variable like final String nonExistantName = "WHATever it is";
4 (commented on others PR)
I think? this is fine, but I'm not certain. Double check best practice maybe?
5 (commented on others PR)
Good good, Nice to see you not having magic literals.
6 (commented on others PR)
Maybe put in a variable with a descriptive name first like String nameOfPersonToDelete
7 (commented on others PR)
Should this be an invalid name, or would rejecting a number suffice for this test?
8 (commented on others PR)
LGTM, although I personally would prefer 'their' instead of 'his/her'
9 (commented on others PR)
it should be delete NAME, not delete name. All Caps for variables I think
10 (commented on others PR)
Class is wrong and variable name is wrong
11 (commented on others PR)
AddressBook ab should be ContactList cl
12 (commented on others PR)
getTypicalAddressBook should be getTypicalContactList
13 (commented on others PR)
addressBookStorage should be contactListStorage
14 (commented on others PR)
Method name again
15 (commented on others PR)
readAddressBook method is wrong
16 (commented on others PR)
method name is wrong and probably wrong for many test case code
17 (commented on others PR)
variable name differentAddressBook
18 (commented on others PR)
comment has reference to ReadOnlyAddressBook
19 (commented on others PR)
value = "addressbook" is probably wrong 😦
20 (commented on others PR)
addressBook variable name
21 (commented on others PR)
Class name AddressBookStorage
22 (commented on others PR)
Comment is unchanged
23 (commented on others PR)
method name
24 (commented on others PR)
variable name
25 (commented on others PR)
bad comment
26 (commented on others PR)
variable name addressBookOptional and method name readAddressBook
27 (commented on others PR)
method getSampleAddressBook
28 (commented on others PR)
method name
29 (commented on others PR)
comment is bad
30 (commented on others PR)
Also method name
31 (commented on others PR)
variable name addressBookStorage
32 (commented on others PR)
getTypicalAddressBook
33 (commented on others PR)
method name
34 (commented on others PR)
saveAddressBook is bad
35 (commented on others PR)
setAddressBookFilePath 👎
36 (commented on others PR)
method name
37 (commented on others PR)
getTypicalAddressBook is a thorn
38 (commented on others PR)
method name 👎
39 (commented on others PR)
method name and variable name 👎
40 (commented on others PR)
I think this one and this one alone should be unchanged given that it references an external project
41 (commented on others PR)
More bad method names and variable names
42 (commented on others PR)
comment "Converts this address book into the model"
43 (commented on others PR)
I would prefer if you have hash code account for both carBrand and carType
44 (commented on others PR)
Method variables test1 and test2 should be descriptive, like testBrand and testType
45 (commented on others PR)
While good to see, is it best practice to have a feature PR and a bug-fix PR mixed together? Worried we might be penalized for bad PR practice
46 (other comment)
Attributes are "Car" and "CoeExpiry"
@umergta (42 comments)1 (commented on others PR)
i agree with yi hsuen. But for final consensus, lets discuss in the meeting as there is no rush to do so
2 (commented on others PR)
Yes I believe so
3 (commented on others PR)
invalid? Since these are AddressBook tests and everything should be related to ModuleBook3.5 now
4 (commented on others PR)
same issue? Maybe the pull from upstream wasnt done properly as the current master has no invalidPersonAddressBook and is invalidTaskModuleBook
5 (commented on others PR)
testing for AB3, not ModuleBook3.5 😕
6 (commented on others PR)
LGTM! but i agree with yi hsuen. should just be a small fix 😃
7 (commented on others PR)
should be "returns a"
Just a small fix
8 (commented on others PR)
Maybe can paraphrase to "sorts the list of tasks according to the deadline of the task. Tasks with deadlines approaching soon are displayed at the top while tasks with no deadlines are displayed at the bottom"
9 (commented on others PR)
maybe next iterations we can avoid null but looks good for now!
10 (commented on others PR)
good catch haha
11 (commented on others PR)
maybe can save the condition in a boolean to make it clearer instead of having the comment? just a small suggestion
12 (commented on others PR)
was gonna say the same but yes lets discuss
13 (commented on others PR)
nice!
14 (commented on others PR)
can we use enum? just a suggestion
15 (commented on others PR)
just a small issue.. can be a bit ambiguous (name can be interpreted as name of task / name of module) so can be more specific. looks good otherwise
16 (commented on others PR)
should follow the given format e.g. deleteTag 1 t/tagName
17 (commented on others PR)
agreed
18 (commented on others PR)
listOfModules (should be plural). Small issue though
19 (commented on others PR)
idk if extra lines in between if blocks are adhering to 2103t standards.
20 (commented on others PR)
not sure if its better to mention the return like this or use '@return' instead. Just a small issue
21 (commented on others PR)
Looking at the other parse methods in the various commands like add, ArgumentMultiMap and tokenize is used instead of this way of split. Although valid, maybe for consistency sake can use that?
22 (commented on others PR)
im not sure if trimming is necessary here as in ModuleBookParser's parse command, userInput.trim() is already called with the matcher. Good to double check there haha
23 (commented on others PR)
Yes i agree with @QY-H00 here. Was going to mention that highly likely law of demeter is violated here. Although, if u think the violation is justified, its fine (according to prof, can justfiy for convenience sake at times). If not, i think its better to add a method in!
24 (commented on others PR)
think there is too much method chaining going on so may be good to change this implementation? Up to u if you think otherwise.
25 (commented on others PR)
I think the naming of the variables can be clearer here!
26 (commented on others PR)
do you think javadocs required here? since they are public methods?
27 (commented on others PR)
unecessary else block?
28 (commented on others PR)
nice catch!
29 (commented on others PR)
I see that u have an array of valid modules in ur ModuleManager class... I think it will be good if we specify the valid modules in the UG.. if not, it might be reported as a bug later on haha
30 (commented on others PR)
referring to this in the comment above!
31 (commented on others PR)
shouldn't each assignment be on the same line?
32 (commented on others PR)
hmm correct me if im wrong, but youll be adding the raw workload of each task to the module? Maybe, as a better indicator for modules, we can calculate the proportion / fraction of the total workload for each module? I think that wll be a more useful number for the user? Maybe the rest can pitch in here too
33 (commented on others PR)
maybe can remove this commented code out
34 (commented on others PR)
nice haha
35 (commented on others PR)
just a minor suggestion, to change 1,2,3 to low,medium, high for clearer communication through code
36 (commented on others PR)
Minor suggestion: can use for-each loop instead but no biggie
37 (commented on others PR)
nice use!
38 (commented on others PR)
wah didnt know this existed haha
39 (commented on others PR)
think would need to add tests in ModuleManager instead later for the removal of these later
40 (commented on others PR)
looks good!
41 (commented on others PR)
think need to change this java doc!
42 (commented on others PR)
nice avoidance of using magic literals!
43 (commented on own PR)
ok will do
44 (commented on own PR)
done
45 (commented on own PR)
Yes. I think there should be a notRecur command to remove the recurrence of the Task. I think i will work on that Monday after clearing other assignments haha
46 (commented on own PR)
resolved
47 (other comment)
closed. Didn't run CI
48 (other comment)
Done. Waiting to merge in master DG after review
49 (other comment)
done
50 (other comment)
no changes for storage. LGTM!
51 (other comment)
Overall LGTM. Just added some comments pertaining to previous ongoing convos.
52 (other comment)
LGTM
53 (other comment)
LGTM
54 (other comment)
Merged upstream repo into current repo for recurring-command:
Failing testcases (that have been commented out):
JsonSerializableModuleBookTest: toModelType_typicalTasksFile_success()
StorageManagerTest: moduleBookReadSave()
JsonModuleBookStorageTest: readAndSaveModuleBook_allInOrder_success()
55 (other comment)
hmm i definitely agree with you that we shouldnt stay in the middle.
When implementing the recur command, I thought it was a good to have a command on its own because:
Personally, i would have more 'one-time' tasks than recurring tasks if im using a a task manager. E.g. we would only have 1 assignment 1 in a module. So for recurring tasks, realistically speaking, it should be made into a command rather than just a normal field like 'workload' for example. This is also a justification we can give for the criticism on 'why does recur have to be a command on it's own' if we get it?
With regards to your 1st problem, I am not quite sure as to why the book will stop updating weekly? If a task is recurring weekly, it will refresh the deadline every week regardless, no? Might need some clarification there haha sorry
The second scenario is actually a v important consideration. One possible implementation can be when a user marks task as done, we can update the deadline (and remove starttime maybe), so that the user can see the next deadline already? what do you think? Another possible solution would be to maybe add a next deadline: field in the task card which is way simpler i think?
For the refresh command, i think it is a bit unsafe to add a new command with only a day left because I think quite a few changes would need to be made? and we only have (only a day at most) to implemement the feature? I am scared that it will be too tight for v1.3 deadline?
Overall, I am still fine with either though cuz for me, both ways work fine and (i think) either way can be justified hahaha
56 (other comment)
looks good!
57 (other comment)
LGTM
58 (other comment)
resolved in previous issue. solved by @QY-H00
59 (other comment)
linked to refresh command?
@xiinweii98 (38 comments)1 (commented on others PR)
If I remember correctly, the "As a" part don't have to be a user. So in this case maybe we can do: "Cake Collate/Program". But, I tried to find this in the lecture notes/textbook and couldn't find it.
So, maybe we can omit the "So that"/benefit part instead of "(obvious)", since it was mentioned in the notes benefits can be omitted if they are obvious.
2 (commented on others PR)
The full-stop in the benefit part caught my eye haha. Maybe standardize across the DG~
3 (commented on others PR)
Maybe instead of "track", "execute"? Or something along that line.. Because we aren't really tracking the deletion, just actually removing it from the database.
4 (commented on others PR)
Noticed a "/" at the end of the benefit part.
5 (commented on others PR)
Maybe "re-adding" or "adding"? haha
6 (commented on others PR)
Noticed full-stop here as well. Same for a few below this~
7 (commented on others PR)
Noticed you used capital "V" for "View". Maybe standardize and use small caps. Same for the benefits part in line 264 and 267 "My" and "Details".
8 (commented on others PR)
Maybe can leave out the benefits part too.
9 (commented on others PR)
why got another add nub
10 (commented on others PR)
Not sure if the AB3 allows for 2 p/
I think it does but maybe to make it clearer in the UserGuide, just put one phone number
11 (commented on others PR)
Can you add a full stop haha
12 (commented on others PR)
Need to change "person", same for line 29
13 (commented on others PR)
Maybe needs changing/removed
14 (commented on others PR)
Assuming you're asking a question?
I think it would be good to have a way to differentiate or find out if two HelpCards are the same, regardless if we ever use this equals method.
15 (commented on others PR)
Same thing, need to change "persons", same for line 29, 48
16 (commented on others PR)
Maybe add a brief javadoc?
17 (commented on others PR)
Hmm, just from looking at the files changed, I can't figure out why you abstracted out fillPersonListPanel()...
18 (commented on others PR)
Same thing here, but I am guessing because of some dependencies you needed to setRoot(root) before you setController(this)
19 (commented on others PR)
May I know why you are deleting this? Is it because this method is not used?
20 (commented on others PR)
Hmm.. By right the data shouldn't change while the user is in the help panel. But it wouldn't harm to insert redundancies so that the program won't break if for some reason data was changed during the transition. So, I would recommend using this fillPersonListPanel() to populate the personlist panel.
21 (commented on others PR)
Ahhh, I see. We were told cyclic dependencies are bad practices in 1101 right? While its a bad practice I think it is still used haha if you take a look at w8 topics the first video for drawing class/object diagrams, they have cyclic dependency also: box and lid.
Maybe if you want to, you can change the resetMainWindow method in MainWindow to a static method then use a static call in HelpCommandPanel. Not sure if that is still cyclic dependency lol. Else if you really want to resolve it I guess you need an association class.. So, goodluck!
22 (commented on others PR)
"orders" ? instead of "persons"
23 (commented on others PR)
Same thing here, "orders"
24 (commented on others PR)
😮 why is this here? Thought it is supposed to be changed by Pavitra's PR
25 (commented on others PR)
If you're changing such that user can choose the range of dates then you should remove "is within 3 days of the current date" right.
26 (commented on others PR)
You can maybe merge this two if you are not trying to differentiate the reason why there is a parse failure (since you are throwing the same exception). In a way the error message will be less meaningful but it is what the original coder(s) did too for AddCommandParser etc. We discussed this briefly during our last meeting when @pPris brought it up. I think for now we are KIV-ing and maybe changing it if we have time.
27 (commented on others PR)
Should be "order"
28 (commented on others PR)
Same for other usages of "people" and/or "person" for this file
29 (commented on others PR)
Remove this if its not used? 😃
30 (commented on others PR)
He probably needed the request here to create an order item lol. Although it is possible to overload the Order constructor.
31 (commented on others PR)
Maybe for extensibility. Having a prefix in place now means in the future if we want to add another prefix it can be easily done.
Maybe so that user can input more than 1 request per command. Without the prefix, the user may have to use the command twice to input 2 different requests.
I think it's fine leaving it as it is now 😃
32 (commented on others PR)
"diabetus" is on purpose or typo? lol
33 (commented on others PR)
Remove this boi
34 (commented on others PR)
CommandException should be removed
35 (commented on others PR)
Just wondering why you use .value here while you used .toString() in L41?
36 (commented on others PR)
To test "no parameters" you should include all other required fields and only leave out the parameters. I'm guessing you mean to test for the prefix here? Since you are testing index below
37 (commented on others PR)
Same for this, you should only leave out index and include prefix.
38 (commented on others PR)
Remember to remove the cost column~
39 (commented on own PR)
Yup definitely! If I recall correctly Benson's details will be used specifically in some tests. So since you are adding a field as well, take note of those specific test cases that tries to extract Benson's details ya. Probably don't have to do anything about it if you didn't miss anything ~
40 (commented on own PR)
Good catch! Will do.
41 (commented on own PR)
Yup, there are. Nice catch again:)
42 (commented on own PR)
Uhm because I wanted to let the user be able to search for a date using any of the format they use when they add the order + if they input the day/month/year only. Though now that I look at it I probably can do away with day/month/year since they are already included in the 4 formats provided haha. Also, yeah probably can create a method in deliverydate to get formats.
43 (commented on own PR)
Yeap my initial concern was I didn't want to let user be able to use this prefix at all thats why I only create it in the code. Just remember I can create the prefix but not set it as a prefix argmultimap accept haha thanks
44 (commented on own PR)
"or" search is done by the "all/" prefix which concatenate all the fields in an order to search the keywords against. So that becomes like alloforder.contains(keywords)
45 (other comment)
Add a OrderDescription class to seedu.address.model.person and edit the Person class to reflect added field.
46 (other comment)
LGTM~
47 (other comment)
LGTM 👍
48 (other comment)
LGTM 💯
49 (other comment)
LTGM
50 (other comment)
LGTM
51 (other comment)
LGTM
52 (other comment)
LGTM
53 (other comment)
LGTM
54 (other comment)
LGTM
55 (other comment)
LGTM, can always add more next time.
56 (other comment)
LGTM 👍
57 (other comment)
LGTM ~
@chesterhow (37 comments)1 (commented on others PR)
I think we should keep Mainstream OS in the glossary as mentioned in our NFRs
2 (commented on others PR)
Perhaps it would be more consistent if we used 8 spaces here for indentation as well.
3 (commented on others PR)
Should we revert this back to 8?
4 (commented on others PR)
Perhaps we could make dd-MM-yyyy a constant string, since it is also used in line 40
5 (commented on others PR)
Same here for HHmm
6 (commented on others PR)
Indentation should be 8 spaces
7 (commented on others PR)
Same here indentation issue
8 (commented on others PR)
Indentation issue as well
9 (commented on others PR)
Indentation issue as well
10 (commented on others PR)
Same here for lines 132, 133 and 136
11 (commented on others PR)
Duplicate opacity styles
12 (commented on others PR)
Duplicate opacity styles here as well
13 (commented on others PR)
Indentation issues on line 22 and 24
14 (commented on others PR)
Not too sure about this, but should this be private static final?
15 (commented on others PR)
Let's standardise to double quotes for all strings
16 (commented on others PR)
Should be okay to remove the old getMeetingList() and getDateList() which returns empty lists right?
17 (commented on others PR)
I think this can be removed?
18 (commented on others PR)
I think we should add spaces around the ->
19 (commented on others PR)
Extra empty line here
20 (commented on others PR)
I think BIRTHDAY is fine here, or perhaps DATE instead of DATETIME
21 (commented on others PR)
Could we add a "*" multiplicity to Event? Might be good to use labels here as well since there are 2 links to Event: dates and meetings
22 (commented on others PR)
Would be good to standardise the term css to be always in lowercase
23 (commented on others PR)
Do add a space between the hashes and the title itself, as I'm not sure if jekyll can parse the markdown properly without
24 (commented on others PR)
Add a * before the example here for consistency with the rest of the UG
25 (commented on others PR)
Would be better if we used the theme's colours here
26 (commented on others PR)
Should be subtract-debt i believe.
27 (commented on others PR)
Do add a newline after this line
28 (commented on others PR)
Would "provided" sound better here?
29 (commented on others PR)
Copy nit: "Although optimized for Command Line Interface enthusiasts, the intuitive interface allows anyone to get started with it immediately."
30 (commented on others PR)
Copy nit: "This document walks you through the User Interface and Features present in FriendDex".
31 (commented on others PR)
Copy nit: "Your Computer's operating system (OS) needs to be Windows, macOS or Linux, and the OS version you are using should still be supported by the respective companies."
32 (commented on others PR)
"please refer here" sounds a bit strange. Perhaps "please click here"?
33 (commented on others PR)
Since the file is deleted, I think we should just remove this line from the gitignore as well.
34 (commented on others PR)
Maybe use logger instead?
35 (commented on others PR)
I realised your new theme files do not have the .json extension. Not sure if that's intentional
36 (commented on others PR)
Remember to update the documentation to include the new personStreaks param
37 (commented on others PR)
I don't think you need to handle this case anymore as I've removed the time param from the requireAllNonNull check in Event's constructor
38 (commented on own PR)
Hmmm the idea is that it could be used for any kind of special annual date, not just anniversaries. Any other ideas?
39 (commented on own PR)
We can't simply compare LocalDates as we're not taking year into account here, since the events are repeated annually.
40 (commented on own PR)
I'm unable to put them in their respective classes because it requires the Person's name, which is not stored on the Birthday and Event class.
41 (commented on own PR)
yeah its just a label now no styling yet
42 (commented on own PR)
I realised in some places I named it UpcomingDates while in others they were UpcomingEvents. Actually, I just realised in logic it's still called UpcomingDates. I think I'll just revert and switch it all to UpcomingDates.
43 (commented on own PR)
Ok will do. Anyway I think i'll leave it as UpcomingEvents for now. Might rename all in another PR
44 (other comment)
@Assyarul Has this been resolved in #58? I think we can close this if so.
45 (other comment)
Right, my bad I realised my Mac had "Prefer tabs: always" toggled in my sys prefs. Will update the screenshot
@swayongshen (36 comments)1 (commented on others PR)
Would it be possible to link directly to the quick start section as well?
2 (commented on others PR)
Do you think "clients' contact details" will be more suitable?
3 (commented on others PR)
Would it be better to have a static constant for each direction?
4 (commented on others PR)
Would it be better to have static constant for each direction?
5 (commented on others PR)
Is using "sorts" instead of "sort" better as it follows the convention used by the other commands?
6 (commented on others PR)
Do you think that we could use 'insurance policy' instead of 'policy' because it would be more intuitive for the i/ tag that we are using? At least for this section. It seems fine when we are talking about the policy command.
7 (commented on others PR)
Maybe you forgot to change some information after copying them from find command.
8 (commented on others PR)
Is there a use for this logger?
9 (commented on others PR)
Just to clarify Policy_ means even if different insurance companies have different ways to label their policies, they should all be labeled starting with Policy_? E.g. company A labels policies P#12345, company B labels policies Life#7900, the respective policy ids in ClientBook would be Policy_P#12345 and Policy_Life#75900.
10 (commented on others PR)
Would it be better to name the method getPolicyUrl? The if-present characteristic of it is represented by the fact that Optional is used.
11 (commented on others PR)
Perhaps a grammatical error here? Is there a reason why the original comment was changed?
12 (commented on others PR)
Would it be good to also update the user guide to reflect this required format?
13 (commented on others PR)
associated with a selected client?
14 (commented on others PR)
Maybe "delete client contact" instead, to be consistent with add and edit.
15 (commented on others PR)
"hence" sounds redundant when the line is read.
16 (commented on others PR)
Could use INDEX instead of "The index", to clearly indicate that you are talking about INDEX in the command.
17 (commented on others PR)
This line suggests that only 1 optional attribute can be added, while one of the example below shows multiple optional attributes being used. This can be confusing to the reader.
18 (commented on others PR)
Did not state explicitly what the flags are used for. The usage is clear to us as we are the developers.
Also, would it be better to list the flags in a table? Idk
19 (commented on others PR)
A suggestion would be "The delimiter & between keywords allows you to search for Clients using multiple keywords."
20 (commented on others PR)
Can draw similarities with list function. E.g. "Similar to the list command, optional attributes can be added to show only certain attributes in the search result"
21 (commented on others PR)
Aside from the example on sorting by name, do you think an example on sorting insurance policy is needed?
22 (commented on others PR)
Maybe "After setting a password, the application" or ClientBook instead of application.
23 (commented on others PR)
ClientBook's ClientBook password
24 (commented on others PR)
ClientBook's password is removed.
Suggestion: Future launches of ClientBook will not require a password?
25 (commented on others PR)
Currently the json is stored in a zip file regardless of whether it is locked. If its locked then there's a password to the zip file.
26 (commented on others PR)
A suggestion: "schedules a meeting on a particular date and time with a client in Clientbook"
27 (commented on others PR)
Is this line consistent with what is said for other similar features that require an index?
28 (commented on others PR)
Do you think having at least 1 screenshot to display the expected response will help the reader?
29 (commented on others PR)
This is missing in the user guide.
30 (commented on others PR)
Do you think the field name should be renamed to meetings to reflect that multiple meetings can be inside? Please also update other similar namings in this file.
31 (commented on others PR)
Could you abstract/SLAP some part of this to reduce the length?
32 (commented on others PR)
Although this is the default implementation by AB3, would it be better to do the typecasting only once?
33 (commented on others PR)
Do you think it is better to follow the existing convention? I.e name the list meetingList just like policyList.
34 (commented on others PR)
Does this imply that delete meeting deletes all meetings? Could you explain this implementation vs deleting just 1 particular meeting?
35 (commented on others PR)
Not sure how this works but does it validate the date? E.g. if I put 30 Feburary will it reject? It is up to you to decide if it is needed.
36 (commented on others PR)
Does this mean you did not update the test case to accomodate meetings?
37 (commented on own PR)
Done
38 (commented on own PR)
Have changed Tag into InsurancePolicy @ line 24. Will be keeping the JavaDoc comment to follow the JsonAdaptedTag class from which I adapted the code.
39 (commented on own PR)
Appreciate the feedback! However that was the format that came with the incumbent code e.g. DeleteCommand's equals().
40 (commented on own PR)
Yes, the original intent is for unlock command to work even without CURRENT_PASSWORD if ClientBook is not locked. However, in hindsight this is confusing for the user and I have changed CURRENT_PASSWORD to be a compulsory argument in the UG.
41 (commented on own PR)
That is a great suggestion actually.
One possible way would be to encrypt a password file using a secret key within our code which when the program runs, will be decrypted and stored in program state and encrypted immediately.
The user can then enter lock without any parameters to lock using the old password.
However, I do feel that the effort to return ratio is rather minimal as it does not make our program any more tailored for our user than what already exists.
42 (commented on own PR)
Good point there, I was looking at the same API a few days ago too. The methods ZipFile.isEncrypted() and ZipFile.extractAll() did not specify which type of ZipException was thrown. The try blocks are separated because I was using the second exception to return false, while the first try block was used to catch the error thrown when checking if the zip file is encrypted.
43 (commented on own PR)
It was to make it clear during usage that there is no password involved as someone reading it may interpret as entering an empty password.
44 (commented on own PR)
Fixed.
45 (commented on own PR)
Thanks for the feedback! Turns out String.split() will return an array with 1 element when the string is an empty string. A similar problem in UnlockCommandParser has also been fixed.
46 (commented on own PR)
I agree, I have updated the method's name to improve clarity.
47 (commented on own PR)
You are right. Actually carrot probably refers to just ^. Will be changing to what you have suggested.
48 (commented on own PR)
I believe the test name is correct because I'm testing the equals method to be successful when two UnlockCommand with the same currentPassword fields are tested to be equal.
49 (commented on own PR)
That's a comment from the code base, no idea.
50 (other comment)
No idea why gradle build fails on Github when it passes on my system.
51 (other comment)
lgtm
52 (other comment)
Thanks for the review. Will be merging it
53 (other comment)
Some of the links can be updated to point to our repo. Currently they are pointing to ab3's repo.
54 (other comment)
I recommend you clone this https://github.com/swayongshen/tp/tree/add-lock and do some general testing.
55 (other comment)
I have implemented the new feature of saving the old password. When the user calls the lock command to set a new password, the password will be stored in an encrypted file named keystore in /data/.
After unlocking ClientBook, the next time the user tries to lock ClientBook without a password, the old password will be decrypted from the password file and added to the state of the program and the password file will be encrypted immediately.
56 (other comment)
LGTM! Perhaps you might want to add this in to the User Guide too?
You are right, I have added it to the features section as well as created a Summary of Keyboard Shortcuts section.
@Md-Fazil (36 comments)1 (commented on others PR)
Should the command be find instead of search?
2 (commented on others PR)
Would it be better to name the field expiryDate to date? I think it would not be as ambiguous and would be easier to understand.
3 (commented on others PR)
Instead of first checking if the expiry date format is correct using regex, he parses the input right away and catches DateTimeParseException to determine if the specified input is a valid expiry date. I think it will still work as intended.
4 (commented on others PR)
Should this nonNull check for expiryDate be removed?
5 (commented on others PR)
Should this be "Sorts the items from the inventory" instead?
6 (commented on others PR)
Would it be clearer if we state "sort quantity will display the items in the inventory in ascending order of quantity."?
7 (commented on others PR)
I think we can provide example usage similar to how the other commands provide it currently as well.
8 (commented on others PR)
I think it is fine to leave it as it is as this is just a custom comparator. Perhaps, the naming of the class can be better.
9 (commented on others PR)
Would this message usage be misleading and give users the idea that both tag and location can be specified? Would it be better if the message usage is [l/LOCATION]/[t/TAG]?
10 (commented on others PR)
Would it be better if it explicitly states "user-specified number of days from the current date..."?
11 (commented on others PR)
Perhaps, you can try checking both conditions for trimmedArgs and numOfArgs in one if block and throw a ParseException to avoid repetition?
12 (commented on others PR)
I'm assuming this is not case-sensitive. Does it mean that "Weeks" would not match "weeks"? If that is the case, we have to clearly specify this in the user guide.
13 (commented on others PR)
I think this way of checking would break if the user keys in "reminder 3" with 2 spaces instead of 1. This way " 3" your argument would be " 3" which would cause a number format exception which would be caught and eventually be thrown as a parse exception. Are we going to be strict about this? Currently, the other commands don't seem to take into account additional spaces in between prefixes and command word.
14 (commented on others PR)
Can you clarify the way you are parsing?
15 (commented on others PR)
I agree with Jay as well. I think it would be less ambiguous and would be standardised across the commands.
16 (commented on others PR)
Does this violate the law of demeter since you are getting an object from item and accessing its field?
17 (commented on others PR)
I believe Item should provide a method that retrieves expiryDate directly.
18 (commented on others PR)
AB3 used address book and it's name interchangeably. In our case, our UG uses StoreMando and inventory as the two terms to refer to the app. Would it be better if you change all the usages of address/location book to inventory instead?
19 (commented on others PR)
As mentioned above, this could be "causing another modified inventory state to be saved into the storeMandoStateList."
20 (commented on others PR)
My personal opinion is that the welcome message should just be "Welcome to StoreMando!". Just a suggestion to consider.
21 (commented on others PR)
I agree with Kumaran. I think it should be written as "User searches for items that are expiring within the next 3 days".
22 (commented on others PR)
I think this should be written as "User inputs a negative number".
23 (commented on others PR)
Perhaps, I think this step should be removed.
24 (commented on others PR)
I think can it would be better to phrase it "User requests to delete all items in a specific location".
25 (commented on others PR)
I think this should be "prompts the user for a correct location".
26 (commented on others PR)
Would the benefit be clearer if we specify "I want to clear all the items in my room at once so that I do not have to waste time manually deleting all the items in my room"?
27 (commented on others PR)
Should this be "StoreMando prompts the user for the correct input"?
28 (commented on others PR)
Should we be writing this as "with the aim of helping users manage their items effectively and efficiently". Since this is a more description of the project, I think using the same tone as user guide would not be appropriate. What do you think?
29 (commented on others PR)
Similarly, I think we should avoid using first person in this section and write it more formally.
30 (commented on others PR)
I think we should personalize all success messages as a whole to differentiate the individual features rather than returning a generic message for all clear/list/sort command types. Maybe this would be a good place to start and we can improve on this in the coming iteration. What do the rest think?
31 (commented on others PR)
Personally, I think this does not follow the single layer of abstraction principle. Perhaps, one suggestion would be to create a method (ie; clearLocation) in the class responsible for managing the lists and call the method here.
32 (commented on others PR)
Yes, I think this would not work with additional spaces as well using equals.
33 (commented on others PR)
This method name states that parsing an empty argument would throw parse exception but you are testing for parse success. Perhaps, you might want to change the method name.
34 (commented on others PR)
Maybe you can consider adding spaces between prefixes and test all possible valid inputs.
35 (commented on others PR)
Can we abstract it out further? This method calls setItems method of model class and retrieves model's own attribute to pass back as a parameter. I think we can create a method to abstract this out further.
36 (commented on others PR)
Can you clarify how is the parsing is handled? Would this break if there is an additional space passed in?
37 (commented on own PR)
Fixed
38 (commented on own PR)
Fixed.
39 (commented on own PR)
Fixed.
40 (commented on own PR)
fixed.
41 (commented on own PR)
fixed.
42 (commented on own PR)
Agreed with Wei Hao. I think it is fine to leave it as it is since there is no fixed input format and prefixes can be specified in any order.
43 (commented on own PR)
Fixed.
44 (commented on own PR)
Thanks for the suggestion. Fixed.
45 (commented on own PR)
This follows the original setup. I think it's fine to leave it as it is for now.
46 (commented on own PR)
We can leave it as it is for now as mentioned above.
47 (commented on own PR)
Value was used to standardize across all the fields an item model is composed of. I think it would be more consistent if we leave it this way.
48 (commented on own PR)
I think we can display the warning in red color in our GUI instead of using all caps to warn. I feel it would be friendlier that way.
49 (commented on own PR)
Fixed.
50 (commented on own PR)
I think it is still fine as the class MainWindow has helpwindow as the immediate neighbour and I'm passing the URL as an argument to the displayWebsite method in BrowserUtil.
51 (commented on own PR)
Thanks for the suggestion. Fixed!
52 (commented on own PR)
Upon further thinking, I have shifted it as per your suggestion as it was more practical. Thanks and fixed!
53 (commented on own PR)
Alright, fixed!
54 (commented on own PR)
I think both are fine but I'll change it to make it clearer.
55 (commented on own PR)
The anchor tag will not be displayed and only the hyperlinked quick start will be displayed.
56 (commented on own PR)
I have updated the features section header to contain the anchor tag. Thanks for pointing it out!
57 (commented on own PR)
Yes. This has been included in the existing user guide and I did not make any changes to it. Therefore, it is not highlighted in this pull request as a change.
58 (commented on own PR)
Fixed!
59 (commented on own PR)
I think it is better to be as explicit as possible in the user guide and there is no harm in doing so.
60 (commented on own PR)
As mentioned above, I think it is fine to leave it as it is. Perhaps, we can get the opinion of others as well.
61 (commented on own PR)
The subheaders will appear in bold when displayed in HTML so it will still be fine.
62 (commented on own PR)
Thanks and fixed.
63 (commented on own PR)
Thanks and fixed.
64 (commented on own PR)
Thanks and fixed.
65 (commented on own PR)
Yes, I have changed it.
66 (commented on own PR)
Noted on that and I have fixed it according to your suggestion. Thanks!
67 (commented on own PR)
Noted and I have fixed it accordingly. Thanks!
68 (commented on own PR)
Fixed.
@candyhy (36 comments)1 (commented on others PR)
Maybe you can consider correcting imports with *? Could be why your code failed the style check.
2 (commented on others PR)
you could actually just add your new property details to TypicalProperties file under testutil rather than editing the default values of property builder
3 (commented on others PR)
Should it be property book instead of address book here?
4 (commented on others PR)
Remember to update the javadocs here too
5 (commented on others PR)
Remember to update the javadocs here too
6 (commented on others PR)
haha think it shouldn't matter but for future reference I think u should just add it to the TypicalProperties file ba 👍
7 (commented on others PR)
a suggestion bc I don't think its good to initialise the variables to null:
Name name;
Contact contact; etc
8 (commented on others PR)
consider use of split function for more concise code?
9 (commented on others PR)
oh I see, because the toString may not contain the variable. ok nvrm then haha
10 (commented on others PR)
okk I see that u updated the function to use length function 👍 I just found the '13' and other indexes to be random
11 (commented on others PR)
Should this be combined into one line?
12 (commented on others PR)
Should this be combined into one line? 120 characters per line does not apply to DG
13 (commented on others PR)
Should this be combined into one line?
14 (commented on others PR)
Should PersonListPanel be updated to PropertyListPanel and AppointmentListPanel?
15 (commented on others PR)
should "the person whose name contains the keywords" from the original address book be removed?
16 (commented on others PR)
don't think your eclipse setting files should be included
17 (commented on others PR)
I see, ok
18 (commented on others PR)
are your diagrams to be inserted later?
19 (commented on others PR)
these too
20 (commented on others PR)
should this be 'undo'?
21 (commented on others PR)
are these to be added later?
22 (commented on others PR)
How about 'the property list will now be in descending order based on price'?
23 (commented on others PR)
I think this doesn't sound very user friendly? A user may not know what a parameter is
24 (commented on others PR)
should we explain what does Option, Sales and Purchase Agreement, and Completion mean?
25 (commented on others PR)
Don't think the user will know what does status refer to
26 (commented on others PR)
is this supposed to be [PROPERTY_TYPE] instead?
27 (commented on others PR)
think the 'Both done at the same time' is unnecessary? If anything, maybe 'simultaneously' will be better
28 (commented on others PR)
I meant line 265 266, there's this [remarks], this that supposed to be the case?
29 (commented on others PR)
I think can keep the part act the first property having highest price at the book though, although the phrasing for the first half is good now
30 (commented on others PR)
do u think ClientBuilder should be used for this?
31 (commented on others PR)
same for this
32 (commented on others PR)
should PropertyBuilder class be used?
33 (commented on others PR)
should AppointmentBuilder class be used for this?
34 (commented on others PR)
are these supposed to be commented out?
35 (commented on others PR)
this too
36 (commented on others PR)
ok
37 (commented on own PR)
fixed!
38 (commented on own PR)
fixed as well
39 (commented on own PR)
Fixed, thanks!
40 (commented on own PR)
fixed
41 (commented on own PR)
done
42 (commented on own PR)
Fixed as well:)
43 (commented on own PR)
Nope, if you guys are agreeable with the new LightTheme Ui, I will go ahead and delete DarkTheme.css
44 (commented on own PR)
I would say it's not impossible but the purpose of adopting a light theme was to allow the greying out of expired property and appointments to be somewhat observable yet inconspicuous. The grey effect in the already Black/Grey DarkTheme would probably not achieve the same effect. However, if you guys are keen on a dark theme, I can consider a DarkTheme design in a subsequent update- maybe keep the DarkTheme.css file for now
45 (commented on own PR)
oh yes ok will update this
46 (other comment)
Code style issue at ../src/test/java/seedu/address/logic/commands/RemarkCommandTest.java:40: no newline at EOF.
47 (other comment)
hey, I've fixed the bug that doesn't display postal code. However, about price, have to consult junwei on this because he is adding the price of the property as client info actually, not as part of property attribute itself
48 (other comment)
not implemented, to be considered after v1.4
49 (other comment)
50 (other comment)
@candyhy what do you think of this 🤔
I think it is too colourful, better to keep it minimalist. That purple doesn't go with the blue either
51 (other comment)
can I also suggest keeping the text wrapping fixes and changes to Ui as separate pull requests? cos I think its imperative to fix the text wrapping but the Ui may not be satisfactory yet
52 (other comment)
can I also suggest keeping the text wrapping fixes and changes to Ui as separate pull requests? cos I think its imperative to fix the text wrapping but the Ui may not be satisfactory yet
created a separate pr for text wrap!
cool thanks! 👍
53 (other comment)
@candyhy what do you think of this thinking
I think it is too colourful, better to keep it minimalist. That purple doesn't go with the blue either
what colour would you suggest?
I think its better to keep the background white/black. shouldn't have more than 3 colours in a Ui in my opinion
54 (other comment)
Updated StorageClassDiagram
55 (other comment)
Storageinterface should extendPropertyBookStorage,AppointmentBookStorageandUserPrefsStoragetoo
will update this too
56 (other comment)
new StorageClassDiagram
57 (other comment)
ohya can u upload your diagrams here for everyone to see?
@garyljj (35 comments)1 (commented on others PR)
should be [-t TAG...]
2 (commented on others PR)
same here, should be [-t TAG...]
and im not sure whats that special char. but if its intentional then no problem!
3 (commented on others PR)
Cancel, not a typo
4 (commented on others PR)
For the ... , are multiple tags searches allowed? Doesnt seem to be allowed atm
5 (commented on others PR)
rename to sortPersonList since not the filtered list being sorted
6 (commented on others PR)
suggestion:
This one our userguide currently is "tags" too but would "tag" be better?
7 (commented on others PR)
public static final String MESSAGE_USAGE = COMMAND_WORD + ": Lists all tags and the count of persons tagged in the Hippocampus. "
8 (commented on others PR)
Prefer like that haha but this one up to you
model.getAddressBook()
.getPersonList()
.forEach(p -> p.getTags()
.forEach(t -> tags.compute(t, (k, v) -> v == null ? 1 : v + 1)));
9 (commented on others PR)
boolean noNameAndTag = noName && noTag;
10 (commented on others PR)
want to use .contains for search tag too?
11 (commented on others PR)
just to standardise with other parser classes if you want haha
ArgumentMultimap argMultimap = ArgumentTokenizer.tokenize(args, PREFIX_FIND);
Optional<String> keyword = argMultimap.getValue(PREFIX_FIND);
if (keyword.isEmpty() && argMultimap.getPreamble().isEmpty()) {
return new TagsCommand(tag -> true);
}
12 (commented on others PR)
Add new line
+ "person tagged in Hippocampus.\n"
13 (commented on others PR)
Swap error message
} catch (DateTimeException err) { // date in wrong format
throw new IllegalValueException((Birthday.MESSAGE_CONSTRAINTS));
} catch (IllegalArgumentException err) { // birthday year exceeds current year
throw new IllegalValueException(Birthday.MESSAGE_YEAR_CONSTRAINTS);
14 (commented on others PR)
IllegalValueException was correct haha
IllegalValueException is the one caught by storage. Or else an invalid date in the save file will not be handled and program will terminate
throw new IllegalValueException(Birthday.MESSAGE_CONSTRAINTS);
15 (commented on others PR)
I think she was following the wording of constraint for address field. Do yall think it would be good to change that too? or we can leave both too
16 (commented on others PR)
I believe the == check here was intentional cos it is checking the exact object (the static string).
Otherwise LGTM
17 (commented on others PR)
For marking event as done (in the event branch)
I simply used list.contains() since that uses .equals() to check.
May be slightly less efficient time complexity wise, but could be more readable. Which do yall prefer?
If prefer this then LGTM, i can update the other
private DeleteContactCommand createDeleteContactCommand(String args) throws ParseException {
String[] strIndexes = args.split("\\s+");
List<Index> indexes = new ArrayList<>();
for (String s : strIndexes) {
Index index = ParserUtil.parseIndex(s);
if (!indexes.contains(index)) {
indexes.add(index);
}
}
return new DeleteContactCommand(indexes);
18 (commented on others PR)
Here can just leave it as DATE.
Since to the user, event date is basically a date (unlike birthday where they are extra restriction).
Or if decide to keep, put it as one word EVENTDATE, or else it seems like 2 arguments
+ "[" + PREFIX_DATE + " DATE] "
19 (commented on others PR)
Might have missed out this? Not sure if it affects other stuff, but after i changed it looked better haha
.list-view {
-fx-background-insets: 0;
-fx-padding: 0;
-fx-background-color: derive(rgb(243, 229, 231), -10%);
-fx-border-color: white;
-fx-border-width: 1;
}
20 (commented on others PR)
Alternative to probably make it simpler and slightly more efficient
private void checkIfHasTags(Person personToCheck) {
Set<Tag> personTags = personToCheck.getTags();
for (Tag targetTag : targetTags) {
if (personTags.contains(targetTag)) {
editedPersons.add(personToCheck);
return;
}
}
}
21 (commented on others PR)
Toggles between Dark and Pastel theme
22 (commented on others PR)
* Constructs a {@code GuiSettings} with the default height, width, position, and theme.
23 (commented on others PR)
* Constructs a {@code GuiSettings} with the specified height, width, position, and theme
24 (commented on others PR)
public static final String MESSAGE_USAGE = COMMAND_WORD + ": Toggles PartyPlanet's theme between Dark and Pastel.";
25 (commented on others PR)
commandResult = new CommandResult(String.format(MESSAGE_SUCCESS, "Pastel"), false, Theme.PASTEL);
26 (commented on others PR)
Optional: can be private?
private void setThemePastel() {
27 (commented on others PR)
Optional: can be private?
private void setThemeDark() {
28 (commented on others PR)
Missed out in initial suggestions
* Toggles the theme of PartyPlanet between Dark and Pastel.
29 (commented on others PR)
This makes sort_upcoming unable to work with asc/desc.
Isit intented? If so then just remember to document
Same for list
30 (commented on others PR)
Make sense! just making sure it isnt an oversight
31 (commented on others PR)
This makes sort_upcoming unable to work with asc/desc.
Isit intented? If so then just remember to document
Same for list
32 (commented on others PR)
Oops comment was meant for PR 180, shifted over
33 (commented on others PR)
Suggestion to use setOnKeyReleased then no need use a generic event handler.
Also to combine duplicated event handlers
commandTextField.setOnKeyReleased(e -> handleUndoRedo(e));
history = new InputHistory();
}
/**
* Handles key combination releases.
* Exceutes undo command if CTRL + Z shortcut is used
* Exceutes redo command if CTRL + SHIFT + Z or CTRL + R shortcut is used
*/
private void handleUndoRedo(KeyEvent event) {
if (undo.match(event)) {
try {
commandExecutor.execute("undo");
} catch (CommandException | ParseException e) {
setStyleToIndicateCommandFailure();
}
} else if (redo1.match(event) || redo2.match(event)) {
try {
commandExecutor.execute("redo");
} catch (CommandException | ParseException e) {
setStyleToIndicateCommandFailure();
}
}
}
34 (commented on others PR)
if (orderType.isEmpty() || comparator == SORT_EVENTDATE_UPCOMING) {
if (!stringSort.isEmpty() && comparator != SORT_EVENTDATE_UPCOMING) {
stringSort += "in ascending order. ";
}
return comparator; // default
35 (commented on others PR)
if (orderType.isEmpty() || comparator == SORT_BIRTHDAY_UPCOMING) {
if (!stringSort.isEmpty() && comparator != SORT_BIRTHDAY_UPCOMING) {
stringSort += "in ascending order. ";
}
return comparator; // default
36 (commented on own PR)
Maybe is just the phrasing confusing. So in the latest commit I phrased the main info as
If provided with tags
Delete every person who is tagged with the specified tag.
If the person is tagged with another tag, only the specified tag will be removed. The contact will not be deleted.
Then for these examples, I left it as
delete -t colleague -t cs2103 deletes contacts with tag "colleague" and contacts with tag "cs2103"Cos the happy path is to delete the contact. Then ONLY IF it is tagged with another tag then the contact is not deleted.
37 (commented on own PR)
Did not change, discussion is below
38 (commented on own PR)
Edited but phrased a little differently, check latest commit
39 (commented on own PR)
public static final String MESSAGE_DELETE_PERSON_SUCCESS = "Deleted the following persons: %1$s";
40 (commented on own PR)
Yup makes sense!
Edited, info in comment below
41 (commented on own PR)
Could not find a simple way to make tags the outer loop for containAllTags().
So kept persons as the outer loop for both All and Any, for readability.
However, made use of TagsContainsExactTagPredicate as suggested for better abstraction (demeter law)
42 (other comment)
LGTM
43 (other comment)
LGTM
44 (other comment)
LGTM
45 (other comment)
LGTM
46 (other comment)
LGTM
47 (other comment)
LGTM
48 (other comment)
Also update userguide to include this command
49 (other comment)
Yup I considered this but thought it was too inefficient to scan through all whole list to see if all tags specified exists.
Perhaps I can add some kind of static set in Tags to keep track of all tags that currently exists
50 (other comment)
I implemented a similar feature in my IP so I can probably PR later and see if yall like it
51 (other comment)
Actually, since year not really important for a birthday, maybe we can store it in a MonthDay object instead. Then no need request year input at all.
52 (other comment)
Perhaps can also change display of bday in a form of "11 Dec 99" instead of the current 1999-12-11.
53 (other comment)
Alternatively, idea to put the logo as a background. Altho tbh I dont have much idea how to do it haha
54 (other comment)
Added a min height so for aesthetic purposes
55 (other comment)
Is partial search not going to be the default?
56 (other comment)
Yup that might be better. Since we implemented partial in the first place cos it would be more commonly used.
Even if decide to keep it as exact by default, i think would be good to minimally make it non case-sensitive.
57 (other comment)
I think we agreed that memory not really a concern atm since undo history doesnt carry over across sessions.
But i think no harm adding later on!
58 (other comment)
Yea I dont mind. I feel like even ~10-15 undo is probably more than enough.
But i think wait til event branch is integrated with the history too
59 (other comment)
Throwing error is one way, and the ~easy way out~ other way would be to simply document this behavior feature (i.e. only the last sort prefix given is used), just like for the
addcommand. Which do you prefer?
"If a parameter is expected only once in the command, but you specified it multiple times, only the last occurrence of the parameter will be taken.
e.g. if you specify -p 12341234 -p 56785678, only -p 56785678 will be taken"
Yup our UG already states this case. So alls good!
60 (other comment)
Implemented --exact and --any as suggested above
delete -t a -t b deletes any contact that has tag a or b
delete --any -t a -t b same as no flag
delete --exact -t a -t b only delete contact with BOTH tag a and b
Currently contains bug stated in #162 . Will follow the solution of list
61 (other comment)
closed as branched out from wrong branch
62 (other comment)
Split checkToBeDeleted() into
containsExactTags() when --exact flag used
containsAnyTags() otherwise.
Methods above no longer modifiesdeletedPersons list. Addition to deletePersons carried out in execute()
63 (other comment)
not a bug
64 (other comment)
Final functionality as follows
Before: delete -t TAG [-t TAG] was "delete all contact with specified tag, unless they have other tags"
Now: delete -t TAG [-t TAG] delete contacts (in filtered list) that has the provided tag
delete -t a -t b deletes anyone who has both tag a AND tag b, and display persons deleted
If no one deleted, return message These tags do not exist in persons listed. No person removed.
Flag --any
If this flag is specified,
delete --any -t a -t b deletes anyone who has EITHER tag a OR tag b, and display persons deleted
If no one deleted, return message These combination of tags do not exist in persons listed. No person removed.
65 (other comment)
Tested, works well. Note the cosmetic issue:
Latest commit throws error for this issue, updated PR message above
66 (other comment)
Perhaps we can do this one-shot during our upcoming meeting.
sounds good!
67 (other comment)
Optional for @pyuxiang Can update DATE and BIRTHDAY with all valid formats (since we allow many different ones)
68 (other comment)
Rephrase message slighty
"All requirements above met." -> "Results meet all requirements above."
"At least one requirements above met" -> "Results meet at least one requirements above."
@yungweezy (32 comments)1 (commented on others PR)
I think maybe we can use student instead of stu to improve readability
2 (commented on others PR)
Possibly change the use of 'acc' and 'el' here too
3 (commented on others PR)
The change.next() method controls the position of an iterator that goes through the discrete changes in the Student List. Whenever there is a change the listener catches these changes and triggers the contents of the onChanged function. The while loop will terminate after all tracked changes are iterated. Here's the API
4 (commented on others PR)
Yeah, I believe the "calling" to update the ListView is abstracted away in the implementation of ObservableLists in JavaFx under the Observable collections.
I think the reason why we're using ObservableLists is properly summarised in this article.
A ListView bounded by List will not update upon changes, but a ListView bounded by ObservableList will.
5 (commented on others PR)
Correct me if i'm wrong, is this a particular coding standard I do not know of?
6 (commented on others PR)
Might not need to check for same sessions?
7 (commented on others PR)
{@code name}
8 (commented on others PR)
I believe this.value would be better? 🤡
9 (commented on others PR)
I believe this.fee would be better? 🐔
10 (commented on others PR)
Lazy efficient way, I like! 👍🏼
11 (commented on others PR)
I believe this.value would be better? 🐷
12 (commented on others PR)
whitespace missing after @JsonProperty
13 (commented on others PR)
Are we leaving these commented out?
14 (commented on others PR)
This removeSession method seems to be very destructive. Could this probably be student.getListOfSessions().remove(sessionIndex)? 💥 💣
15 (commented on others PR)
Oh shizzle mah nizzle. Roger doger!
16 (commented on others PR)
Hahaha, wait I placed them in brackets because I'm not sure which term we should go with 😄
17 (commented on others PR)
Maybe a typo here? 😅
18 (commented on others PR)
Not sure if capitalization of session here would make a difference.
19 (commented on others PR)
Not sure if capitalization of session here would make a difference since it is referring to the class Session in the javadocs.
20 (commented on others PR)
Might want to add the command deleteSession in UniqueStudentList.
21 (commented on others PR)
I am not entirely sure if the inclusion of the seedu.address and model boxes adds much value here. Maybe the rest can look into this too!
22 (commented on others PR)
Hmm is this change here intended? 🤔
23 (commented on others PR)
For the architecture sequence diagram, perhaps we can change it to a more generic example that @enhao25 sent on the group so that we don't need to update if we were to change commands formatting, and to use this diagram to show the interactions that occur for all commands. ☕
24 (commented on others PR)
Right I guess Java 11 is more appropriate here, unless the distinction isn't that obvious on the page.
25 (commented on others PR)
Sounds good, we should merge the individual changes first.
26 (commented on others PR)
Agreed, dd MMM YYYY would be more reader friendly.
27 (commented on others PR)
Is this perhaps TuitionCard.fxml for consistency?
28 (commented on others PR)
Not sure if it's just on my end but i notice the clear not showing up as intended.
29 (commented on others PR)
Not sure if it's just on my end but i notice the STUDENT_PHONE_NUMBER and GUARDIAN_PHONE_NUMBER not showing up as intended inside of the block.
30 (commented on others PR)
I believe line 121 has an extra indentation.
31 (commented on others PR)
Works fine for me, probably some browser issue?
32 (commented on others PR)
True, also this could possibly make use of the ℹ️ notation we have included.
33 (commented on own PR)
Agreed, I will make the necessary changes.
34 (commented on own PR)
Agreed, I will make changes on the next commit
35 (commented on own PR)
Will need to write test cases for Students!
36 (commented on own PR)
I will check again if there are conflicts with test cases. But the reason for the change was to fix a formatting for the study level field because currently some of the entries differ, eg. "P5", "Sec 2", "JC 1. I understand the consideration for possible less trivial cases like "Uni CS3230", but I believe we should standardise the format, at least for pre-generated data.
37 (commented on own PR)
Did you mean line 80?
38 (commented on own PR)
Possibly for use in the future to differentiate session objects, since we do not assign unique ids to sessions yet. If this is not needed I can remove it!
39 (commented on own PR)
Yes, I wanted to check if the same student with different list would assert to be equals, however I had forgotten to change BOB back to Alice nice spot!
40 (commented on own PR)
Yes you are right, I will resolve in the next commit!
41 (commented on own PR)
ohmilorde thanku
42 (commented on own PR)
Placeholder for next iteration where we add student names into session, will remove for now.
43 (commented on own PR)
I would think so, so that we know the two panels are in sync and the first session will always be from the first student in the list. What do you think?
44 (commented on own PR)
Good point 😊 Will make changes!
45 (commented on own PR)
Yes correct, this is because of the OneBasedIndex that is returned in getSessionIndex(). I will add in a comment to make this clearer!
46 (commented on own PR)
Answered in previous comment!
47 (commented on own PR)
Thanks for spotting, will update.
48 (commented on own PR)
Hahaha, yes I am aware, just thought that I might need to change it next time so might as well copy first. Will remove later on if it is not needed!
49 (commented on own PR)
Were these from AB3? Okay I'll remove the extra forward slashes.
50 (commented on own PR)
Thanks for spotting! 🙏🏻 arigathanks
51 (commented on own PR)
Gotcha
52 (commented on own PR)
Are you referring to line 58? I am aware of that and have thought about it and decided to add it in as well since it wouldn't make sense for me to just check for the range strictly between sessionStartDate and sessionEndDate and have the method named hasOverlappingSession(), though a change in method name to hasOverlappingWithinSession() may be possible. Let me know what you think.
53 (other comment)
Duplicate commit
54 (other comment)
A sketch of the UML with a Tuition class that contains both Student and Session class.
Realised it doesn't add much value to @JonahhGohh's UML but here's a glimpse if anyone's interested.
55 (other comment)
I also noticed all the commands that @enhao25 changed to name it as ____StudentCommand got reverted. Is it intentional?
It is intentional if we were to follow the current implementation of Tuition class, where all student parameters are explicitly declare in the Tuition constructor.
So there will only be 1 TuitionCommand which is the AddTuitionCommand right? The rest like list, delete, find, etc are still StudentCommands?
This is a mistake, good spot, should be AddStudentCommand.
56 (other comment)
Resolved in #43
57 (other comment)
Resolved in #34
58 (other comment)
Change of implementation to hold list of session as attribute of Student class.
Dear me 😭
59 (other comment)
Closed due to change of implementation.
60 (other comment)
Resolved in #53
61 (other comment)
Pulled to #67.
62 (other comment)
Pulled to #73
63 (other comment)
Some comments on testing.
Can you add a parseSessionCommand_list() test case in AddressBookParserTest? #76
Okay! I'll add them in.
64 (other comment)
For quick reference, here's an image of the current UI:
65 (other comment)
LGTM. Not sure if we still need the d in 'd:ListStudentCommand' in your UML sequence diagram. I think that d was used in DeleteCommand and it might be confusing here. I think the best representation is to remove the 'd's all together.
Okay will make changes on the next commit
66 (other comment)
Yeap LGTM. However, there is something that I noticed when checking out the PR and testing it which is outside of the scope of this issue. The duration class allows a duration of 0. Do you think it would be better if we only allow value > 0.
Good point, I'll add a data validation for this!
@wongkokian (32 comments)1 (commented on others PR)
I think it would be better if you could sort the user stories by priority.
2 (commented on others PR)
I think the numbering for this extension should be 1a1.
3 (commented on others PR)
I think this use case should resume at step 3 as the list would still be shown even after the error message, so ClientBook does not have to show it again.
4 (commented on others PR)
A suggestion would be "2a. The list of matched clients is empty."
5 (commented on others PR)
Same here. A suggestion would be "2a. The list of matched clients is empty."
6 (commented on others PR)
Would be nice if can add a screenshot of how the feature works.
7 (commented on others PR)
Would it be possible for the success message to output the attribute that was specified as well? Like "Listed all clients with address attribute as filter."
8 (commented on others PR)
A suggestion will be to do "if (!isAttributeSpecified()) {".
9 (commented on others PR)
One suggestion would be to use switch statements.
10 (commented on others PR)
Same here. Suggestion to use switch statements.
11 (commented on others PR)
Suggestion to name this isFirst to isFirstAttribute to make it more understandable.
12 (commented on others PR)
Same here for the isFirst boolean as mentioned above.
13 (commented on others PR)
I think there is a typo here. Should be "...client management tasks faster than traditional...".
14 (commented on others PR)
Would it be better to define what is "home folder"?
15 (commented on others PR)
Instead of "jar file" maybe you can put "clientbook.jar" with a markup to be more specific?
16 (commented on others PR)
Adds a client named John Doe along with his details to ClientBook.
17 (commented on others PR)
Index has to be within the range of the list as well.
18 (commented on others PR)
Maybe can include an image for the "list -policy" command, since the "list -phone -policy" one already has one.
19 (commented on others PR)
Also can add "An optional attribute option can be added to show the list of matched clients with only the specified attribute."
20 (commented on others PR)
The image format is different from the other images (e.g. the title bar not shown).
21 (commented on others PR)
I think it is okay to remove the OR search part because I think the user might not understand what it is.
22 (commented on others PR)
Same here, about the index being in range of the list.
23 (commented on others PR)
I am not sure if these 2 lines should be in this policy command section. Feels like it should be stated in the add/edit command section where the policies are added/edited.
24 (commented on others PR)
Same here with the index within range.
25 (commented on others PR)
Will be good if can describe how the sort by policy command displays the list. Maybe add an example.
26 (commented on others PR)
I think there is a typo with "exclamation".
27 (commented on others PR)
How about "Copy the file to the folder where you want to store the ClientBook application and your client information."?
28 (commented on others PR)
Yeah, this is much clearer!
29 (commented on others PR)
Yeap, that works too!
30 (commented on others PR)
Like a screenshot of what happens when you perform "sort -i -dsc".
31 (commented on others PR)
I think this part is missing the "FLAG/KEYWORD [& MORE_KEYWORDS]..." part.
32 (commented on others PR)
I think this key should be excluded from the merge.
33 (other comment)
LGTM 👍🏻
@Eriksen2411 (31 comments)1 (commented on others PR)
Agreed
2 (commented on others PR)
wah this is complicated, do you want to split it one by one before return
3 (commented on others PR)
A complicated return also
4 (commented on others PR)
tks for this change
5 (commented on others PR)
You forgot to include the project-index in this message_usage
6 (commented on others PR)
As Samueal commented on my PR before, the getZeroBased method alr checks for negative value, so this is unnecessary
7 (commented on others PR)
tks for the change
8 (commented on others PR)
I'm not sure about this 2, one you taken from address field right, and the original I take from project name.
9 (commented on others PR)
I think for the rest of the pr, it's ok
10 (commented on others PR)
hey samuel I'm not sure about this, but as I see it from javadoc format of other methods, there should be a blank line between description of method and parameter, return, throw
11 (commented on others PR)
I think this is a complicated boolean expression as code quality says about it. You can choose to keep that or separate them 1 by 1
12 (commented on others PR)
should this have a javadoc
13 (commented on others PR)
this 2 method missing javadoc also, as for other builder, you put javadoc for constructor also
14 (commented on others PR)
Ahhh, OK I think that is all I can spot for now. For cases to test, I cannot think of other cases to add.
15 (commented on others PR)
add a blank line in javadoc
16 (commented on others PR)
leave a blank line here too
17 (commented on others PR)
here also
18 (commented on others PR)
can we use requirenonnull for this
19 (commented on others PR)
0 here sounds a little bit like a magic number here, should you put another variable for it?
20 (commented on others PR)
1 here also
21 (commented on others PR)
Here are the variable for it right. you can mention it if possible
22 (commented on others PR)
leave blank line
23 (commented on others PR)
can we use !requrireNonNull here
24 (commented on others PR)
I think for the rest I agree
25 (commented on others PR)
I think this should be userInputInvalidProjectIndex
26 (commented on others PR)
This should be userInputInvalidTodoIndex also
27 (commented on others PR)
I think here should rename also so that it refers to index of project not project.
28 (commented on others PR)
This one's javadoc should have a return statement
29 (commented on others PR)
This one also
30 (commented on others PR)
add blank line for javadoc
31 (commented on others PR)
here also
32 (commented on own PR)
yeah i think its weird yesterday too, but not sure thanks for the comment
33 (commented on own PR)
@vevek Am i addressing your full name correctly
34 (commented on own PR)
resolved
35 (commented on own PR)
resolved
36 (commented on own PR)
resolved
37 (commented on own PR)
resolved
38 (commented on own PR)
resolved
39 (commented on own PR)
resolved
40 (commented on own PR)
resolved
41 (commented on own PR)
resolved
42 (commented on own PR)
resolved
43 (commented on own PR)
resolved
44 (commented on own PR)
resolved
45 (commented on own PR)
resolved
46 (commented on own PR)
ah for this actually the invalid format is thrown above
the parseIndex has its own exception throw for invalid Index. So no problem with this, and actually I change it because if invalid index, the correct exception should be thrown (invalid index), not (invalid fomat)
47 (commented on own PR)
resolved
48 (commented on own PR)
resolved
49 (other comment)
Closes #22
50 (other comment)
Great work 😃 . Can I also suggest adding the role "Developer" to everyone. I feel that it would help reflect our roles clearly.
Agreed
51 (other comment)
Cannot merge because of irrelevance to the project
52 (other comment)
closes #5
53 (other comment)
Omg i just did it again. So sorry @vevek 😃))
54 (other comment)
closes #49
55 (other comment)
i have implemented the addEto command. Please give some input. For the codecov test, that might be because of missing tests. For now, you guys can comment on any logic faults in my code. I will try my best to complete the documentation and the tests for this command asap.
56 (other comment)
And also, i have tried out the code but seems like only the command result shown up. Is it because of the ui not ready yet? Or maybe I don't know how to make that shown up. Please let me know.
57 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
58 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
59 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
60 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
61 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
62 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
63 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
64 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
65 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
66 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
67 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
68 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
69 (other comment)
This issue no longer fits the project as the idea of project changed. Closed for ease of distraction.
@zatkiller (31 comments)1 (commented on others PR)
Remember to change the prefix to what we discussed
addTask title -d description
2 (commented on others PR)
Just want to check if there is a need for this class or can we store the description as a String within the Task?
3 (commented on others PR)
Same question as Description Class. Should we store it as a String instead?
4 (commented on others PR)
Are we supposed to update the person list?
5 (commented on others PR)
Also might need to change the comment here, other than this small issue can merge
6 (commented on others PR)
Should this variable should be renamed to MESSAGE_INVALID_PERSON_DISPLAYED_NAME?
7 (commented on others PR)
Lets standardise the naming to be XXXMemberCommand to make fixing easier
8 (commented on others PR)
Think we can rename this file to DeleteMemberCommandTest to standardise the file naming
9 (commented on others PR)
I think we should make a Util file for the names and import them instead of hardcoding the value here. This makes it easier for maintaining. For example, the TypicalPersons java class in the testutil directory is an example of what I mean
10 (commented on others PR)
Same issue about hardcoding values
11 (commented on others PR)
I thought names should not have prefix?
12 (commented on others PR)
Should we follow the format of the actual phone number -p 95652233 (with spacing)
13 (commented on others PR)
I think we should follow our prefix convention using -. For e.g. -a
14 (commented on others PR)
I think this should be changed to invalid name, try including some alphabets mixed with numbers
15 (commented on others PR)
I think you forgot to change this
16 (commented on others PR)
I think you might be missing the task status for the Card
17 (commented on others PR)
I think here we can return the created LocalDate?
18 (commented on others PR)
Typo?
19 (commented on others PR)
Nice refactoring!
20 (commented on others PR)
Is this a variable name? If its not should we standard the comments of hey matez to Hey Matez? to HEY MATEz?
21 (commented on others PR)
Same thing here, should we standardize according to our app name?
22 (commented on others PR)
Same question here
23 (commented on others PR)
Same question here
24 (commented on others PR)
Same question here
25 (commented on others PR)
I think you missed this folder. But can merge after changing
26 (commented on others PR)
typo lol
27 (commented on others PR)
Here too
28 (commented on others PR)
should be hey matez not address book
29 (commented on others PR)
Shouldn't this be HeyMatez?
30 (commented on others PR)
Should be UndoTaskCommandParser
31 (commented on others PR)
Should be LogicManager
32 (other comment)
Close PR due to extra commits
33 (other comment)
PR Merged. Modifed and Reused Person class. PR #65
34 (other comment)
Just have 1 small thing to check on, which is the updating of updatedPersonList when we are updating tasks. The rest LGTM
35 (other comment)
Add task status to edit of task
Updated UG
Add space behind prefixes to enforce spacing
36 (other comment)
Update UG and Javadocs
Update jar filename and log filename
37 (other comment)
No longer implementing feature
38 (other comment)
Renamed addressbook.json to heymatez.json
39 (other comment)
Not implementing
40 (other comment)
Not implementing
41 (other comment)
Not implementing
42 (other comment)
Tag Class converted to Assignee Class
43 (other comment)
Settled by Tasha
44 (other comment)
Not for merging. For Task Grading Only
45 (other comment)
Not for merging. For Task Grading Only
46 (other comment)
Not for merging. For Task Grading Only
47 (other comment)
Not for merging. For Task Grading Only
48 (other comment)
Not for merging. For Task Grading Only
49 (other comment)
Not for merging. For Task Grading Only
50 (other comment)
Not for merging. For Task Grading Only
51 (other comment)
Not for merging. For Task Grading Only
@JonahhGohh (31 comments)1 (commented on others PR)
Slight change in phrasing:
* The user should take no longer than 1 hour to learn the different functionalities of TutorBuddy from the user guide.
2 (commented on others PR)
Maybe can change it to like that to be more specific?
* A user with above-average typing speed for regular English text (i.e. not code, not system admin commands) should be able to use most of the functionality in TutorBuddy faster using commands than using the mouse.
3 (commented on others PR)
We do not actually need this file. It is from the tutorial for tP from week 6. I don't even know why this is here. But I guess the change is harmless.
4 (commented on others PR)
Actually, I was thinking more on the lines of public Tuition(Student student).
I think passing all parameters of student will make the abstraction level of Tuition class 1 level too low.
5 (commented on others PR)
How about
'Student student = new Student(name, phone, email, address, studyLevel, guardianPhone, relationship);
Tuition tuition = new Tuition(student);'
6 (commented on others PR)
Should we name this DeleteStudentTuitionCommand for more consistency?
Similar to the AddStudentTuitionCommand, we are operating on a tuition object here and not a student object.
7 (commented on others PR)
Instead of returning a new Tuition object when we call edit_student, what about returning a student and replacing the student in the Tuition object?
Because the command name is EditStudentCommand which does not really make sense to return a new Tuition object.
8 (commented on others PR)
I was thinking of tuition.getStudent().getName() but I guess this works well. This is just a design consideration but you can check out "Law of Demeter".
9 (commented on others PR)
TuitionTest replaces StudentTest. What tests should we have here now?
10 (commented on others PR)
What is this hashCode() function for?
11 (commented on others PR)
I think the javadoc comment here should change?
12 (commented on others PR)
Woops, I was using my iPad to review just now, and I might not have seen the code accurately. No issues!
13 (commented on others PR)
Oh ok, let's leave it then!
14 (commented on others PR)
Do you mind explaining the listener part and what the change.next() does? I a bit catch no ball 😅 .
Also, which is the part that calls the view to update the session list every time a session is added?
15 (commented on others PR)
Good suggestion! The isValidSessionDate() should assertFalse correctly to this test case.
16 (commented on others PR)
Since we have the isValidSessionDate() check now, we do not need this try and catch block anymore since it is a guarantee that we will receive a valid dateValue and timeValue in our SessionDate constructor.
There are a few changes to other files regarding this issue as well. I will do the changes once this PR is merged.
17 (commented on others PR)
Is this method needed?
Can we use the showStudentAtIndex method for our session command test cases or do we need to find the exact session in the session list?
18 (commented on others PR)
Ok! 😄
19 (commented on others PR)
Should this be AddressBookParser instead?
20 (commented on others PR)
Hmm, since you mentioned that the AddStudentCommandParser creates both a Student and a AddStudentCommand, would it be better to also mention that the AddStudentCommand executes with the Student object?
21 (commented on others PR)
Should be "Clears all entries in the program: clear"
22 (commented on others PR)
Is the "Tip:" meant to be bolded?
or is this the intended outcome:
23 (commented on others PR)
ohhh ok nice
24 (commented on others PR)
Sounds good. I'll change it on my end.
25 (commented on others PR)
Here the command should be add_recurring_session?
26 (commented on others PR)
Maybe can add a javadoc comment for a description of the CalendarCard class?
27 (commented on others PR)
Same as above, missing javadoc comments
28 (commented on others PR)
Did you forget to remove this? 😄
29 (commented on others PR)
I think can do what Samuel did and abstract this out to an addListener() method.
I think it makes it look neater. I will probably do this for my components as well.
30 (commented on others PR)
not too sure if this condition is needed since this is already checked in hasSession() method.
Same for the other boolean condition below.
31 (commented on others PR)
maybe can explain that in the javadoc comment?
32 (commented on own PR)
Thanks for the catch. I think I might have accidentally refactored all names without noticing. Please see the updated commit.
33 (commented on own PR)
Ok, I will add 23:002 and 23:592. So to double confirm, 23:002 and 23:592 should throw a SessionException, right?
34 (commented on own PR)
Yup, thanks for spotting that, it should be k.
@nowknowing it's the prefix for duration (can be seen in the CliSyntax class in the Parser package).
I chose "/k" because "/l" was already used for STUDY_LEVEL in add_student.
If y'all have a more intuitive prefix letter, do suggest!
35 (commented on own PR)
I use the sessionDate.equals() here instead of session.equals() because I think you created an equals() for Session class already right? @samleewy
36 (commented on own PR)
I guess i could improve it by bringing the targetSessioDate in the outer loop, since there isn't a need to declare the targetSessionDate in every iteration.
37 (commented on own PR)
Ok, thanks for the suggestion. I will add some comments to the test cases to make it clearer. 👍
38 (commented on own PR)
HAHA omg 🥴
39 (commented on own PR)
Thanks for spotting, will make a change to this.
40 (commented on own PR)
What do you think of making it like this?
Returns true if session {@code Session} exists in any of the students in the unique student list
I think this takes away the ambiguity of referring to either the session variable or the Session class.
41 (commented on own PR)
Good point! Can you give an example of how you would phrase it? I'm not sure how best to change it.
42 (commented on own PR)
Yup! I agree with what you said, idm changing to what you suggested instead. Personally, I think code clarity is more important than uniformity in this case.
43 (commented on own PR)
Thanks, good catch!
44 (commented on own PR)
Done!
45 (commented on own PR)
Yup a lot of inconsistencies now. I was thinking of just quickly merging all the UG PRs then I will go through again to standardize.
46 (commented on own PR)
Good suggestion, I will use that! 😄
47 (commented on own PR)
I think we can just keep 'user' for now, and standardize it later once everyone merge? Because I think some parts of the document might have used 'user' also.
48 (commented on own PR)
Got it, I will make the change. Thanks for spotting!
49 (commented on own PR)
Can idm also!
50 (commented on own PR)
ok!
51 (commented on own PR)
Ok updated!
52 (commented on own PR)
Yup it is hardcoded. No worries, I will be working on displaying this info immediately after this is merged since the recurring_session is also merged alr.
53 (commented on own PR)
HAHA ya... T_T I tried damn long to make it go to the extreme right but I just couldn't do it. Maybe I'll create an issue for anyone who wants to try 😆
54 (commented on own PR)
Kinda followed the original StudentCard from AB3.
I think we just keep it? 😅
55 (commented on own PR)
Good point, ill add it in
56 (commented on own PR)
nice catch!
57 (commented on own PR)
Good catch!
58 (commented on own PR)
hmmm because I put commas at the end that's why it's left like this.
or should i just remove the commas?
59 (commented on own PR)
Added!
60 (commented on own PR)
I decided to remove the commas and capitalize
61 (commented on own PR)
ok!
62 (commented on own PR)
I personally think it looks neater displaying all in one paragraph 😅
63 (commented on own PR)
seems to work. ill refactor all to this format
64 (commented on own PR)
i googled and it says both also can but "indexes" is a more English way while "indices" is a more latin way haha
65 (commented on own PR)
actually right, i tried to use your onSessionDate() method but because I needed to pass SessionDate in as input, i found it very troublesome to use it. My this build method has the added benefit that it uses the time info of the recurring session, so i don't have to retrieve it, create a new SessionDate and then pass it into the onSessionDate() method.
66 (commented on own PR)
Yes i'll try and clean this method up
67 (commented on own PR)
ohh ok, that's a good idea! I will change it to this.
68 (commented on own PR)
hmmm, but i'm kind of using these variables above as well.. if i create them in the method then I'll have to create them twice..
69 (commented on own PR)
yes, the way I created is hardcoded to only show 3 days. If they change it, then the program will be buggy. I will add the assert statements thanks!
70 (other comment)
Removed. I was actually intending to replace the github logo, but the github logo makes more sense in this case.
71 (other comment)
Add test cases for time 23:002 and 23:592 and both throws a SessionException as expected.
72 (other comment)
I also noticed all the commands that @enhao25 changed to name it as ____StudentCommand got reverted. Is it intentional?
73 (other comment)
So there will only be 1 TuitionCommand which is the AddTuitionCommand right? The rest like list, delete, find, etc are still StudentCommands?
74 (other comment)
I will add test cases for AddSessionCommandTest and AddSessionCommandIntegrationTest later today #61.
Should not cause any issues.
75 (other comment)
closes #49
76 (other comment)
Yeap LGTM. Just 1 small comments on adding comments to the equals method. Previously in the group, I think shion also mention that changing the session to store student instead of having student store session could be a possible idea. If we somehow decide to do that, not sure if some of the test case needs to be changed. However, at this point, it might not be time efficient to change, might need to discuss this future when we meet tmr, to see if there is a point in doing that. Else, looks good
I think regarding this, wouldn't it be better to just have these test cases now and modify them later if we were to introduce the functionality?
77 (other comment)
@samleewy I think the comments change and parse method name change, I'll create a new issue so that we can discuss. For now, maybe you can approve this first to fix the trim date bug?
78 (other comment)
I think having at "Fees" is fine.
79 (other comment)
LGTM, tried out the new UI and its looks great to me. Only has some minor suggestions for you to consider. We could possibly change the reminder to show for the next 3 days instead of the next week instead, once calendar is up, as it wouldn't make sense for both to show the dates for the next 1 week ah.
Can change also, but the main difference is that the calendar should show the week (Mon - Sun), whereas the reminder shows one week from today.
Added benefit for having a Calendar is that it would allow the user to have a sensing of the frequency of tuition sessions for a particular week.
But I agree with you that reducing the period to 3 days improves the functionality of the Calendar.
80 (other comment)
To add on:
add_rec_session n/STUDENT_NAME d/START_DATE e/END_DATE b/INTERVAL t/TIME k/DURATION s/SUBJECT f/FEE
vs e/ and b/ at the back for the actual command message for add_rec_session
81 (other comment)
Oh ps didn't click on the latest commit 😅 . Let's merge then!
@dvdweien (31 comments)1 (commented on others PR)
is the space supposed to be there?
2 (commented on others PR)
should there be two seperate commands for property and appointment?
3 (commented on others PR)
shouldn't it sort the filtered list?
4 (commented on others PR)
should it be filterby or sortby? same for the rest below
5 (commented on others PR)
yeah, sure
6 (commented on others PR)
waaaah thanks for helping me update mine!!
7 (commented on others PR)
nice!
8 (commented on others PR)
is there supposed to be something else after the and?
9 (commented on others PR)
would it be better to initialize it in the constructor?
10 (commented on others PR)
i think it could be permanent, but idk
11 (commented on others PR)
Thanks for doing this!
12 (commented on others PR)
thanks!
13 (commented on others PR)
why is the example usage removed?
14 (commented on others PR)
that makes sense
15 (commented on others PR)
i like the colour you chose
16 (commented on others PR)
izzit possible to have something to toggle between light and dark themes?
17 (commented on others PR)
i see
18 (commented on others PR)
undone? idk my english is quite jialat
19 (commented on others PR)
i think there is a typo, i think us should be is
20 (commented on others PR)
asking price might have decimals too, would using the regex defined in asking price help?
21 (commented on others PR)
may i know whats changed here?
22 (commented on others PR)
waaah bro, thanks man!!!!
23 (commented on others PR)
nice catch!
24 (commented on others PR)
ROFLMAO
25 (commented on others PR)
shouldn't it be FindPropertyCommand?
26 (commented on others PR)
thanks again man!!!
27 (commented on others PR)
would "Forgot when you are supposed to meet Simon again? Let's try finding it out!" be better?
28 (commented on others PR)
maybe only set the text to red when the time has passed like you have already done in appointment and property card?
29 (commented on others PR)
actually, would using the ArgumentTokenizer be better?
30 (commented on others PR)
same for here
31 (commented on others PR)
thanks man!
32 (commented on own PR)
i was thinking like the recognized fields will still be updated and shown to be updated in the list, should i phrase it differently?
33 (commented on own PR)
personally, i think i would prefer 1 if i were a user but would also want to be alerted that there were erroneous fields however, i think it would be best to follow the add command. Like if add aborts the whole command, i think edit should abort the whole command too just to be consistent
34 (commented on own PR)
Ahhh, pesky IDE. Thanks!
35 (commented on own PR)
Thanks for catching it! should all be fixed now
36 (commented on own PR)
Thats true, would changing the default values of property builder be alright though, then I wouldn't have to edit again
37 (commented on own PR)
Thanks for catching this! should be fixed!
38 (commented on own PR)
You have a good eye! should be fixed!
39 (commented on own PR)
thanks! fixed!
40 (commented on own PR)
shld be fixed!
41 (commented on own PR)
noted, though i should warn you, i would probably be doing the same thing for appointment to keep it consistent XD
42 (commented on own PR)
IDE complains that the variable might not be initialized if i dont put leh
43 (commented on own PR)
that would be one way of doing it, i just find this way easier
44 (commented on own PR)
I was thinking of using this to validate that there is only 1 new/proceed/cancel
45 (commented on own PR)
but have not written the code out fully yet
46 (commented on own PR)
yeah, cos it has to implement the status interface, and completion is like the end point. Is there a better way to resolve this issue?
47 (commented on own PR)
nice catch! i used scenebuilder, it must have changed things automatically
48 (commented on own PR)
same for this
49 (commented on own PR)
and this
50 (commented on own PR)
thanks!
51 (commented on own PR)
moved it! thanks!
52 (commented on own PR)
i think you are right, made the prefixes consistent!
53 (commented on own PR)
removed it!
54 (commented on own PR)
removed this too! thanks!
55 (commented on own PR)
added more words, is it better now?
56 (commented on own PR)
updated!
57 (commented on own PR)
updated too! thanks for catching it!
58 (commented on own PR)
added the code to ensure that there is only 1 new/proceed/cancel
59 (commented on own PR)
oh yeah, nice catch!
60 (commented on own PR)
added a check to raise an exception if proceed is used on a property with a Completion status
61 (commented on own PR)
moved it!
62 (commented on own PR)
same as above
63 (commented on own PR)
oh yeah! thats a good idea! thanks!
64 (commented on own PR)
Revamped the prefixes!
65 (commented on own PR)
yeah, these too
66 (commented on own PR)
Nice catch! thanks will change it
67 (commented on own PR)
yepp!
68 (commented on own PR)
yeah, yet to learn plantUML will add next week
69 (commented on own PR)
maybe we can tackle find in another pr?
70 (commented on own PR)
its just a convenience function, i can use the static variable as well but it would look like "String.format(MESSAGE_MISSING_ALL_PROPERTY_APPOINTMENT, command, command, command,
command, command, command)"
71 (commented on own PR)
i see
72 (commented on own PR)
changed it!
73 (commented on own PR)
ok! changed it!
74 (commented on own PR)
i tried my best to match the find format!
75 (commented on own PR)
I tried elaborating more, Is there a better way to phrase it? Was wondering if adding Option, Sales Agreement, Completion to the glossary would be good as well
76 (commented on own PR)
added in elaboration!
77 (commented on own PR)
added in a table!
78 (commented on own PR)
i tried my best to follow it
79 (commented on own PR)
changed the table to a list
80 (other comment)
should I close this pull request?
81 (other comment)
LGTM, thanks for the tremendous effort
82 (other comment)
i think the refactoring is pretty good, can make things easier
83 (other comment)
open to suggestion for colours as well, I can try modifying the whole thing to be more like a light theme oso. I just generally prefer dark themes.
84 (other comment)
i think can lose the underline, maybe the bold isn't needed oso. I was just confused why every date was red
85 (other comment)
in that case, i think just bold is enough underline looks a little ugly to me
86 (other comment)
@candyhy what do you think of this thinking
I think it is too colourful, better to keep it minimalist. That purple doesn't go with the blue either
what colour would you suggest?
87 (other comment)
can I also suggest keeping the text wrapping fixes and changes to Ui as separate pull requests? cos I think its imperative to fix the text wrapping but the Ui may not be satisfactory yet
created a separate pr for text wrap!
88 (other comment)
LGTM but do you want to put the class diagram as a separate PR since you are not using it in the UG yet?
oops, my bad. Removed it!
89 (other comment)
@candyhy what do you think of this thinking
I think it is too colourful, better to keep it minimalist. That purple doesn't go with the blue either
what colour would you suggest?
I think its better to keep the background white/black. shouldn't have more than 3 colours in a Ui in my opinion
like this?
or this?
90 (other comment)
91 (other comment)
- This shouldn't be execute(undo) right
- I think should enclose the parameter in quotes cuz its supposed to be a string
- should be dotted line for returning
- This is a constructor call, so the label shouldn't be 600000 I think. Either leave it blank or change it to a call to create a new Option object
- should be dotted line for returning
- should be dotted line for returning
- missing returning dotted line (if everywhere else has a returning dotted line, then u should probably include one here too)
Thanks! I will fix 1-6 but for 7 i was thinking that cos its a void method and doesn't return anything so I omitted it
92 (other comment)
Your diagram:
My diagram:
For this, I do agree that the 3 child classes should have a composition relationship with
Offer, and I will update my diagram. But do you think there should be a dependency arrow fromStatustoOfferas well?
I don't think there should be a dependency arrow from Status to Offer as Status doesn't actually have any knowledge of Offer, Offer is only referenced in the classes that implement Status
93 (other comment)
the updated sequence diagram
94 (other comment)
I don't think there should be a dependency arrow from Status to Offer as Status doesn't actually have any knowledge of Offer, Offer is only referenced in the classes that implement Status
Ohh, because I thought
Statushas a method returning anOfferobject. Hmm, not really sure whether to include this dependency arrow...
Oh yeah! I forgot about that, that method isn't currently being used now should i remove it? If it shouldn't be removed then i will add the dependency arrow
95 (other comment)
I don't think there should be a dependency arrow from Status to Offer as Status doesn't actually have any knowledge of Offer, Offer is only referenced in the classes that implement Status
Ohh, because I thought
Statushas a method returning anOfferobject. Hmm, not really sure whether to include this dependency arrow...
Oh yeah! I forgot about that, that method isn't currently being used now should i remove it? If it shouldn't be removed then i will add the dependency arrow
Ohh, its not being used? Then ya please remove and I will update my diagram. Thanks!
I just removed it!
@tjtanjin (30 comments)1 (commented on others PR)
I think there might be some settings in your editor that are automatically modifying whitespaces/newlines of the code because this is actually a tutorial file.
2 (commented on others PR)
Same as the above comment, awkward whitespaces in the method header comments.
3 (commented on others PR)
Can consider removing this since we are not checking for duplicate endpoints or it might eventually get flagged as dead code.
4 (commented on others PR)
Find command was only applied to names in AB3 but ours is likely to include all fields in the search. The test here may be referenced for implementing tests for our version of the find command.
5 (commented on others PR)
Might want to be careful of this. Our application might not need this additional check as even having the same method/url may not mean they are the same if the data being sent is different (i.e. data in request body in a POST request)
6 (commented on others PR)
To add on, I think it's possible to check for duplicates but in this case every single field (including tags) would need to match (unlike just name and address in the original AB3).
7 (commented on others PR)
I think the check has been performed in isValidMethod below 😄
8 (commented on others PR)
I think there's a good chance more tests will be breaking given how the header and data attributes have not been implemented yet. At the same time, I am also hesitant about commenting out all the test cases.
The consideration I have is that making several small fixes to pass them might be easier compared to having to make a single big change to all test cases at the same time. Depending on the implementation for header and data, ensuring the test cases pass now may prevent further complications down the road. Just a thought 😄
9 (commented on others PR)
Should there be a newline here?
10 (commented on others PR)
Might be good to populate the sample data in the correct format even though currently they are just stored as string when entered e.g for data it would be '{"key": "value"}'
11 (commented on others PR)
Just a small point but the comments are not updated here.
12 (commented on others PR)
Maybe instead of listing find command twice can differentiate the 2 ways to use it while listing it just once because on first glance it looked like a duplicate (similar to how run was listed).
13 (commented on others PR)
Might help to mention that this is the second format since the previous one said 2 formats.
14 (commented on others PR)
I think the match for ftp and file are not necessary since they are not protocols we support.
15 (commented on others PR)
Minor typo here 😛
16 (commented on others PR)
Need to update the links here 😄
17 (commented on others PR)
Need to replace instances of AddressBook and Person 😄
18 (commented on others PR)
Minor thing but "an Address" might sound better :3
19 (commented on others PR)
Links here need to be fixed.
20 (commented on others PR)
Should the Person reference be replaced with Endpoint instead of Method?
21 (commented on others PR)
Looks much cleaner now! 😄
22 (commented on others PR)
Minor typo for endpoint here.
23 (commented on others PR)
Same typo as above.
24 (commented on others PR)
Should it be find command instead?
25 (commented on others PR)
Using an add might sound more correct here.
26 (commented on others PR)
Just a suggestion but you may want to consider using the >kbd> tag so that the keyboard input are nicely formatted like this: >kbd>ctrl>/kbd> + >kbd>up>/kbd>
27 (commented on others PR)
Nit picking at this point but some bullet points have full stop and some don't :3
28 (commented on others PR)
Actually would it be better to use an actual url that works here? Just in case people actually paste this url to try and because it doesn't work, they flag it as a bug ._.
29 (commented on others PR)
Good catch!
30 (commented on others PR)
Since the method name has changed perhaps the parameter name should be updated as well
31 (commented on own PR)
Just to leave an update here:
The team has had an internal discussion and reviews will be left open to all members of the team (except the PR author) for now. This is slated to change as the project grows and the codebase becomes more complicated.
32 (commented on own PR)
I actually considered this! Then I saw that the other files were not doing it this way so I thought to just follow what's already there as closely as I could :3
33 (commented on own PR)
This was required to address the error raised: not on FX application thread; currentThread = Thread-4
34 (commented on own PR)
I agree the animation should be further improved down the line 😄
35 (commented on own PR)
Thank you for catching that, it's fixed! 😃
36 (commented on own PR)
There's no check for header to be in json format. As an example, the header will be added in this format: -h "Content-Type: application/json". That said, when retrieving the individual key and value, I noticed that this was what I got: ["Content-Type: application/json"]. Hence, I trimmed the brackets and quotations to obtain the key and value. Ideally, the headers should be processed before being stored but until then this will still work 😄
37 (commented on own PR)
Great suggestion, changed this in the latest commit! 😃
38 (commented on own PR)
Reduce the spacing between the title (guide) and the subtitle (version number) xD
39 (other comment)
Great photo! @tjtanjin By the way, there is this slight distortion on the center-right edge of the photo, not sure if you have noticed it. If you don't mind I will go ahead and approve it.
On close inspection, I realized that you added this
[[homepage](https://tjtanjin.com/)]in front of theGithub and portfoliolinks. While I have no issues with the inclusion, I wonder if moving it to the back ofGitHub and porfoliowill make it more standardized? This is because not everyone might be adding their homepage link. What do you think?
I like the suggestion for shifting homepage link to the back, have updated it accordingly 😄 With regards to the image I will source for a better one at a future date but this should suffice for now 😅 Thanks!
40 (other comment)
Resolved with #75
41 (other comment)
@tlylt Thank you for taking the time to scour through the changes 😄 It is indeed a lot of updates at once and I should have provided more context in the PR message. Regarding the points you raised, here are some of the missing context (which have now been included in the original PR message as well):
The refactoring was done partly through IntelliJ and partly by hand, and during the refactoring by IntelliJ, certain imports were automatically changed (such as the one involving Messages and CollectionUtil that you mentioned). I have previously combed the files in general but a few of these change in imports were not caught (though the latest commit should have caught all if not most of them).
The change of seedu.address to seedu.us.among was a result of a brief discussion but it has not been cast in stone, so please feel free to suggest alternatives to the package names 😄
Finally, this PR changes only names and terminologies with no update to the logic at all so test cases would still need a separate update eventually :>
Hopefully these help provide more context 😄 I'll proceed to merge the PR for now and we can do a future PR to rectify stuffs if necessary, thank you!
42 (other comment)
Closed as checks failed to run when github actions went down earlier.
43 (other comment)
Resolved by #95
44 (other comment)
The image seems broken, could you double-check?
Thank you for pointing that out 😄 It's fixed now 😄
45 (other comment)
Addresses #112
46 (other comment)
Addressed by #111
47 (other comment)
The
SendRequestclass perhaps can be more aptly named asRequest? Given that we are indeed modeling a thing that is calledRequestand the wordSendseems redundant.
Just my 2 cents, other than that LGTM
Ok I renamed the logic classes under endpoint and renamed the execute method to send as well which sounds more apt: new GetRequest(endpointToSend).send();
Merging it since the changes are small 😄
48 (other comment)
@tlylt I tinkered around with this as well. Unsure if there is any lag reduction but I imagine we can play around with the initial text to set in the box to mask this from the users. The counter is just a placeholder, I will likely replace it with Processing Command... (the dots will change between having 1 to 3 dots to reflect progress). Just 2 key points I wish to bring up:
Firstly, although it works, the current code implementation feels rather messy because I had to wrap Platform.runLater a good 4-5 times around codes. If you had a better way to implement this, I'd love to hear it. If it helps, the reasoning behind my many uses of Platform.runLater is to deal with an error saying not on FX application thread; currentThread = Thread-4
Secondly, I did the UI threading within the MainWindow#executeCommand but this would mean that sometimes, even the fast commands like add and remove will see a quick flash of the counter (the pseudo progress indicator currently). Resolving this within MainWindow would look very messy as well. I am also still looking for a way to improve this.
I will tidy up and abstract parts of the code as much as I can tomorrow and try my best to make a PR before the team meeting so that we can further discuss this.
49 (other comment)
Great job, while you are at it, could you reduce the 5-second delay that emulates the wait time of an API response 🥺
Curious:
- how did you fix the lag?
- if we are disabling the user's ability to input while running the request, wondering if it will be better if we still show what he entered in the command box and clear it after the request is done? Not sure if this is the case already... for discussion only
I'll make a PR really soon to remove the wait time :3
Shifting Platform.runLater above the sleep code removed the lag (which came from the initial 1 second sleep)
Yup the entered command stays in the command box when frozen 😄
50 (other comment)
Not sure if I am getting this right, the request is cast to HttpPost for all the requests?
The setEntity method is unable to be called on HttpUriRequest and hence the casting. Whether this casting will be universal will be looked at again when more methods are added. If there is a need to then further abstraction needs to be done here 😄
51 (other comment)
Resolved in #145
52 (other comment)
Note:
User header input needs to be enclosed in quotations for example: -h "Content-Type: application/json".
Need to remove above mentioned quotations before storing.
Important:
The second change directly affects the parseHeaders method within HeaderUtil.java. When updating this, change the following line:
headerString = headerString.substring(2, headerString.length() - 2);
headerString = headerString.substring(1, headerString.length() - 1);
53 (other comment)
I think this is a great suggestion, since v1.2 is being wrapped up let's do it in v1.2b 😄
54 (other comment)
Addressed ever since Person was morphed into Endpoint.
55 (other comment)
Addressed in #125
56 (other comment)
interface as in the screen?
I think this is referring to the endpoint list on the left panel.
57 (other comment)
Sample endpoint 3 periodically returns an empty result with the following error:
"JavaFX Application Thread" java.lang.StackOverflowError
There is no known way for the user to directly cause it as of the time of writing this. It seems completely random. What is worth pointing out is that sample endpoint 3 returns a
very long json resultwhich is also reflected in the extra 1 second it takes to load the result into display.
This seems to be a performance issue and we should consider how to address this as soon as possible.
Have tried a few times and wasn't able trigger it, if it is a peculiarity with regards to this API, perhaps we should remove it as of now.
I think it's alright we can leave it there and hopefully it will appear again (happened twice to me so far) so that we can look at it. I am thinking to catch the stackoverflow error but not sure if that's actually legitimate.
58 (other comment)
Would this compromise the command line friendliness since it involves using the mouse to hover?
59 (other comment)
Might have a potential fix to this. Will look at using appendText in ResultDisplay and update again.
60 (other comment)
Another update, I tried both appendText as well as ListView instead of TextArea in our ResultDisplay. In all cases, the lag still features prominently and because the bug is not deterministic, I am also unable to tell if either of them actually fixes anything. With all that said, I have come across quite a number of threads discussing about the performance of JavaFX and in particular, it seems TextArea is not good for very lengthy strings. In fact digging deeper there's quite a lot of criticisms for JavaFX performance. With all that said, I will likely opt to catch the stackoverflow exception.
Note: I cannot tag prof damith here but I'll find time to clarify if this can actually be considered a bug of ours. If truly it is because JavaFX is unable to support such lengthy input without crashing, then hopefully it might be considered an inherited bug.
61 (other comment)
If the length of response is a concern, perhaps we can check the response length and limit that to a reasonable number such that we display a proper error message when the length exceeds that.
My concern is that this might be considered a bug as if we consider the fact that our application causes "loss of data" when calling an endpoint. Will really need to clarify soon.
62 (other comment)
Yup this is not high priority so we can try this out and discuss some time later.
63 (other comment)
Ok nvm I misinterpreted this. List command does seem useless given how our list is always showing, but without list, if you do a find command and get a subset of endpoints you have no way of going back to seeing all endpoints again. This is unless find command supports a wildcard search or defaults to showing all endpoints if no arguments are given but at this point it seems easiest to just keep list.
64 (other comment)
Closed in #232
65 (other comment)
Resolved in #166
66 (other comment)
Possible duplicate of #148
67 (other comment)
Looks good! As discussed, it would be even better if the background image scales with the screen size as well 😃
68 (other comment)
This behavior is also seen in CURL so I think it will be a good enhancement 😃
69 (other comment)
@tlylt @ong6 Is this discussion still ongoing or can it be closed?
70 (other comment)
Currently if a field is blank it states No Data, does that resolve this issue? @ong6
71 (other comment)
Closed by #259
72 (other comment)
I did a quick skim of the files and it seems that the whitespace removed from the likes of PREFIX_METHOD are instead being introduced in the strings they are being concatenated with. Am I overlooking anything?
73 (other comment)
LGTM!
Do you want to also change the example commands at the top and the command summary at the bottom? If not, I can do it 😃
Thank you for catching those, I have updated them with a commit 😄
74 (other comment)
I did a quick skim of the files and it seems that the whitespace removed from the likes of
PREFIX_METHODare instead being introduced in the strings they are being concatenated with. Am I overlooking anything?
Hi the only thing in the PR that affects code is the prefixs being changed in CliSyntax.java. For the add, edit and run, I just made the error command messages more readable, for example: from
"add -xget -usomeurl -hsomeheader" to
"add -x get -u someurl -h someheader"
Okie @ong6 introduced the whitespace in PREFIX_METHOD in this commit 5 days ago so I think's best for him to do the review.
75 (other comment)
@ong6 May I clarify on what the updates for the above commands are in the user guide? I missed this and just merged a user guide update :X
76 (other comment)
Resolved with the function to add endpoint and send them again simply by calling an index.
77 (other comment)
Resolved with the current result display showing API responses.
78 (other comment)
Resolved with the application currently having a very simple design and clear information for endpoints.
79 (other comment)
Resolved with the functionality of send command.
80 (other comment)
Resolved with the API responses being returned in result display and being stored in imposter.json.
81 (other comment)
Resolved with the current capabilities of the application to allow easy testing of APIs.
82 (other comment)
Resolved with the current API calls returning a response time.
83 (other comment)
Resolved with the support for tagging of endpoints.
84 (other comment)
Resolved with the show command displaying responses from the last run of an API call.
85 (other comment)
@tjtanjin the run and send test lowly unreliable they sometimes pass sometimes fail on my comp and I couldn't even commit my work on sourcetree.
Strange if it's inconsistent, if it happens again can create an issue for it and then paste screenshots of the error messages easier to debug 😄
86 (other comment)
Resolved since all features are now supported conveniently through command line or keyboard shortcuts.
87 (other comment)
Resolved in #280
88 (other comment)
Resolved with the enhanced find and tagging functionality for endpoints.
89 (other comment)
Duplicate of #8
90 (other comment)
@AY2021S2-CS2103T-T12-4/developers Just a note that this also remains an important issue with regards to the aspect of UI refinements for v1.3.
91 (other comment)
I think it's not stated obviously but the background is suppose to differ from theme to theme and both dark and light theme has a plain background currently 😅 To clarify the bug for light theme is obvious once you only have like one endpoint left in the left panel.
92 (other comment)
@tlylt Very detailed help prompt, looks ready to be merged! 😃
93 (other comment)
The endpoint associated with this error returns a response body of length above 800000 and infrequently crashes in JavaFX when setText is called. There seems to be no better way to improve performance for this in JavaFX (have tried ListView, staggering the setting of text etc). As this lies with performance issues in JavaFX, it is more practical to address this in our requirements where we "cap" the length of response body for a reasonable performance of the application to be less than 100000.
94 (other comment)
Thanks and sorry for the conflicts!!!!
All good xD Thanks 😄
95 (other comment)
Refer to latest issue at #310
96 (other comment)
Resolved with the now more detailed error messages.
97 (other comment)
Seems similar to what @ong6 suggested in issue #312 except his was for the clear command. Might want to entertain possibilities of solving both these issues at once.
98 (other comment)
Resolved with the current features of our application.
99 (other comment)
Yup I agree that makes sense can update it 😄
100 (other comment)
Is this going to be added in the form of a new feature?
101 (other comment)
If this gets added before the night can update the UG as well? 😄
102 (other comment)
Resolved as current application provides sample APIs.
103 (other comment)
With the guides and application near completion, ease of use has been achieved.
104 (other comment)
Possibly discuss the progress on this task in the afternoon meeting. From my perspective, I think the UG styling & structure are of decent quality, largely thanks to @tjtanjin. If all features are finalized, perhaps everyone could go through the UG at least once again just to make sure no stones are left unturned.
There were some new points brought up after the UG today. They are mostly small details and should not be a lot of work. I agree that everyone should go through the UG at least once again, before the mock PE.
@pyuxiang (29 comments)1 (commented on others PR)
2 (commented on others PR)
3 (commented on others PR)
Use case ends.
4 (commented on others PR)
1a1. HippoCampus shows an error message.
Use case ends.
5 (commented on others PR)
Extra space.
+ "for more information refer to https://ay2021s2-cs2103-w16-3.github.io/tp/UserGuide.html\n"
6 (commented on others PR)
Extra newline.
+ "help [COMMAND]";
7 (commented on others PR)
Missing exit command.
+ "edit INDEX [-n NAME] [-p PHONE_NUMBER] [-e EMAIL] [-a ADDRESS] [-t TAG]…\u200B [-b BIRTHDAY]\n"
+ "Exiting application: "
+ "exit\n"
8 (commented on others PR)
This is a little confusing. By deleting the contact when no more tags exists, it suggests that contacts cannot have no tags. But what about a workflow where user wants to delete all tags, then assign new tags from scratch?
Should the delete -t command just deal with tag deletion alone, and not touch contact deletion at all?
9 (commented on others PR)
I think using the current add, find, delete for contact processing is a good idea, like what you mentioned. That's essentially the existing commit: "deletes all contacts with at least one of colleague or cs2103 tags".
It's the proposed change that I don't quite catch, i.e. "delete tags in contact + delete contact if there is an exact tag match".
PS: On this note, going by your suggestion to use tags exclusively for tag, we can do tag deletion using the same command, e.g. tags -d -t colleague -t cs2103. Sounds like a pretty self-consistent idea.
10 (commented on others PR)
Cos the happy path is to delete the contact. Then ONLY IF it is tagged with another tag then the contact is not deleted.
What about the case where I want to delete all people with that tag? I can't quite think of a viable workaround for this, except manually searching for and deleting the person, e.g.,
# Removing everyone tagged A requires `delete 1 2` instead of `delete -t A`
1. John (tag: A)
2. Grace (tag: A, B)
3. Bob (tag: B)
But I guess these issues only arose because we didn't define the feature well enough in the feature request.
11 (commented on others PR)
Missing space.
+ "Example: " + COMMAND_WORD + " -n Bob -t CS2030";
12 (commented on others PR)
Probably an extension of using string validation, difficult to predict all possible user errors.
13 (commented on others PR)
Might want to change to } else { style recommended in this module.
14 (commented on others PR)
Screenshot of what @garyljj is referring to:
15 (commented on others PR)
* Parses a {@code String remark} into a {@code Remark}.
16 (commented on others PR)
* @throws ParseException if the given {@code Remark} is invalid.
17 (commented on others PR)
Perhaps best of both worlds: "You can write anything in the remarks, as long as it is not blank".
18 (commented on others PR)
Perhaps a more natural phrasing?
public static final String MESSAGE_DELETE_PERSON_SUCCESS = "Deleted the following people: %1$s";
19 (commented on others PR)
Might have to consider a different phrasing later, once the --append flag for tags is added in as well. Should be fine for now.
20 (commented on others PR)
+ "OR " + COMMAND_WORD + " " + FLAG_REMOVE + ": Removes specified tag from all people in the filtered list.\n"
21 (commented on others PR)
The recursive string concatenation is technically quadratic here, though it's probably negligible for small number of Strings. Can consider .map(...).collect(Collectors.joining(", ")); from this SO post.
22 (commented on others PR)
If implementing, can consider allowing removeTagFromPerson to return a boolean reflecting the tag removal success, just like the boolean isEdited = tags.remove(targetTag); line you used in line 49.
23 (commented on others PR)
On a related note, since model.addState() should not be called if no tag removal operations were performed, I think doing the check would be a good idea. Ties in with the same idea.
24 (commented on others PR)
Sure. If got time, I can probably do a quick separate PR for all occurrences.
25 (commented on others PR)
There is an existing predicate for tag testing, if intending to integrate with the existing Person model. Will require addition of a new predicate to separately check for all tags.
for (Tag t: targetTags) {
Predicate<Person> predicate = new TagsContainExactTagPredicate(t.tagName);
for (Person person: personList) { // this can be refactored into separate method as usual
if (predicate.test(person)) {
deletedPersons.add(person);
}
}
}
26 (commented on others PR)
* @throws ParseException If an error occurs during parsing.
27 (commented on others PR)
PREFIX_DATE, event.getEventDate().value,
Update EventDate attribute reference, changed after refactoring of Date object in #180.
28 (commented on others PR)
I'm amazed that this works, because I don't actually see the overloaded method in KeyCombination
29 (commented on others PR)
Scratch that, it's the KeyCodeCombination class, not KeyCombination
30 (commented on own PR)
31 (commented on own PR)
@zhengruoxin yup, also noted here. I couldn't find a way to solve this invalid date mapping problem, without having to move towards manual date parsing. Was planning to document this quirk in the UserGuide and leave it be, since adding the wrong date is not within normal use anyway.
32 (commented on own PR)
Sounds good, it should be more efficient that way. Will make the change.
33 (commented on own PR)
This should be better:
Assuming in typical use scenarios, the number of unique indices specified is not large (pretty unlikely)
Since the application does not require strong performance optimization, readability should be a priority
Will apply suggestion and merge.
34 (commented on own PR)
Remove references to HashSet with change in algorithm, discussed below.
35 (commented on own PR)
Yes, very much intended, because sorting in "reverse upcoming" doesn't seem to have a use case. Will be documenting this eventually.
Think it's a good idea to support it?
36 (commented on own PR)
Thanks for the suggestion! Implemented the alternative algorithm as separately discussed earlier, see upcoming commit.
37 (other comment)
Quality requirement: HippoCampus should be usable by a novice who has never used a CLI addressbook before.
HippoCampus should be able to hold up to 1000 contacts without noticeable sluggishness in performance for typical usage.
Should store data locally only, in a human editable text file, for privacy reasons.
Technical requirements: HippoCampus should work on any mainstream OS with minimally Java 11 installed.
Notes about project scope: Should only be for a single user and should not require interaction with other users of HippoCampus.
A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
The source code should be open source.
Glossary: Mainstream OS: Windows, Linus, Unix, OS-X
38 (other comment)
Duplicate of #17
39 (other comment)
Duplicate of #19
40 (other comment)
Description expanded in #22 #23 #24
41 (other comment)
LGTM
42 (other comment)
LGTM
43 (other comment)
No guarantees it'll work right out the box, but it's a start.
44 (other comment)
Confirmed working. Can close once all checks are done.
45 (other comment)
@nickyfoo commit at d1d7501. All completed.
46 (other comment)
Adhere to more generic command line conventions
47 (other comment)
For a more extreme (cherry-picked) examples, see these workflow runs:
https://github.com/AY2021S2-CS2103-W16-3/tp/actions/runs/607362934
https://github.com/AY2021S2-CS2103-W16-3/tp/actions/runs/588668416
https://github.com/AY2021S2-CS2103-W16-3/tp/actions/runs/586381555
https://github.com/AY2021S2-CS2103-W16-3/tp/actions/runs/585966335
MacOS delayed the check completion due to running 4+ mins.
48 (other comment)
Alternatives to dropping workflows include using skip actions keyword in commit message to skip tests, but not a healthy habit to adopt.
49 (other comment)
LGTM
50 (other comment)
Courtesy of @nickyfoo, cannot reduce automated tests until one iteration is complete, for grading purposes:
https://nus-cs2103-ay2021s2.github.io/website/admin/appendixE-gitHub.html#tp-workflow
After following the given workflow for at least one iteration, optionally, you may adjust the process rigor to suit your team's pace. Here are some examples:
- Reduce automated tests: Automated tests have benefits, but they can be a pain to write/maintain. It is OK to get rid of some of the troublesome tests and rely more on manual testing instead. The less automated tests you have, the higher the risk of regressions; but it may be an acceptable trade-off under the circumstances if tests are slowing you down too much. There is no direct penalty for removing tests. Also note our expectation on test code.
- Reduce automated checks: You can also reduce the rigor of checkstyle checks to expedite PR processing.
- Switch to a lighter workflow: While forking workflow is the safest (and is recommended), it is also rather heavy. You may switch to a simpler workflow if the forking workflow if you wish. Refer the textbook to find more about alternative workflows: feature branches workflow, centralized workflow. Even if you do switch, we still recommend that you use PR reviews, at least for PRs affecting others' features.
Can postpone discussion until the time comes.
51 (other comment)
Duplicate feature already present as a Tag in AB3.
52 (other comment)
Duplicate of clear feature already present in AB3.
53 (other comment)
In particular, adjusting sample data to follow new functionality.
54 (other comment)
@zhengruoxin perhaps some ideas on additional datetime formats that we can provide: https://github.com/pyuxiang/ip/blob/master/src/main/java/duke/parser/DatetimeParser.java
55 (other comment)
Probably here, where the dimensions for the result display are specified:
Overall window size seems to be specified here:
56 (other comment)
Experimented a little with dynamic resizing by setting VGROW to ALWAYS, but it scales together with the person list UI pane, which seemed a little weird: there is no longer an intuitive fixed reference by which the application grows.
For more text, I think the more appropriate action is to limit help text to at most 4 lines.
57 (other comment)
According to the UserGuide, we're also removing the need for -n to specify the name, i.e. add John instead of add -n John, but not yet implemented. We can open a separate issue for this.
58 (other comment)
Also need to change the help message.
59 (other comment)
Issue #81 opened to address the -n prefix issue.
60 (other comment)
@Ellevy mentioned that find and edit also use the same -n prefix, can maintain in add for consistency.
The todo is now to change the syntax in the documentation to include the -n prefix.
61 (other comment)
Courtesy of @glennljs: Issue only happens when gradle run command is used. If built normally and open the jar, it works fine. Perhaps grade adds the font as a separate resource internally.
62 (other comment)
If not fixing, can assign tag::wontfix, remove the priority label, and close the issue.
63 (other comment)
Duplicate of #49
64 (other comment)
Duplicate of #67
65 (other comment)
PR erroneously requested, closed.
66 (other comment)
Note that merging this is a big priority - will introduce a lot of merge conflicts with subsequent PRs.
67 (other comment)
Doesn't the current algorithm involve iterating through the list to check for tags? A quick is_tag_found boolean flag probably works.
If want to extend to existence of multiple tags, can create a boolean flag array as well.
68 (other comment)
Duplicate of #86.
69 (other comment)
Any suggestions to implement this? Thinking of an InputHistory class native to the parser / executor class. Probably also need to register event handlers for up/down arrow keys in the input field box, see this SO post for a possible implementation guide.
70 (other comment)
@zhengruoxin just a heads up, in case you're busy, I'm currently working on a new PR to incorporate the use of LocalDate for validation. Should be done by today.
On Fri, 12 Mar 2021, 13:06 Zheng Ruoxin, @.***> wrote:
@.**** commented on this pull request.
In src/main/java/seedu/hippocampus/model/person/Birthday.java >https://github.com/AY2021S2-CS2103-W16-3/tp/pull/88#discussion_r592912610> :
value = EMPTY_BIRTHDAY_STRING;
isEmpty = true;- }
- /**
* Returns true if a given birthday is an empty birthday.*/- public static boolean isEmptyBirthday(Birthday birthday) {
return birthday.isEmpty;- }
- /**
* Returns true if a given string is a valid email.*/- public static boolean isValidBirthday(String test) {
return (test.toCharArray()[4] == '-') && (test.toCharArray()[7] == '-');That's true. I considered LocalDate but wanted to keep to standardising using isValidBirthday boolean to check for validity. Will try to see if I can use both, else will switch to LocalDate. Thanks!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub >https://github.com/AY2021S2-CS2103-W16-3/tp/pull/88#discussion_r592912610>, or unsubscribe >https://github.com/notifications/unsubscribe-auth/AG2V5DVZTIYF25ESV2G6A2TTDGOMZANCNFSM4Y34E7SA> .
71 (other comment)
Doing iterative addition of features, sample data will be updated concurrently. Not a singular feature.
72 (other comment)
Personally I'd avoid the highly ambiguous "11 Dec 02", partly because it's uncommon, and will succeed without raising errors for international users whose local formats follow "yy/mm/dd" instead of "dd/mm/yy". Perhaps enforcing the "yyyy" format will catch potential errors, or another option would be to allow users to customize the desired date format.
This might be a good reference: https://en.wikipedia.org/wiki/Date_format_by_country
Perhaps the formats we might want to support include the predominant little endian DMY format (exception is ISO format which should always be supported):
"yyyy-mm-dd" ISO-8601
"d.m.yyyy" German, Russian
"d/m/yyyy" French, Spanish
"d-m-yyyy" Hindi
with the associated long forms:
"mmm d yyyy" USA (+ "mmmm d yyyy")
"d mmm yyyy" Singapore (+ "d mmmm yyyy")
73 (other comment)
Closed, not implementing, since bottleneck is no longer workflow runs, but PR reviewing itself.
74 (other comment)
Implemented by #96
75 (other comment)
Is the deletion done across the board, or just for the filtered list?
76 (other comment)
Got confused a little: Isn't the undo command feature part of your PR, and not yet integrated into the master branch? Can raise this issue in the PR first, then open an issue from there if not implemented.
77 (other comment)
What's the syntax to test this?
Courtesy of @nickyfoo: Just "undo". It will undo the last change to the AB (by add, delete, edit or clear).
78 (other comment)
INFO: Added state to stateHistory. Current number of states is: 2. Currently on state: 1 is the logged message. Seems like we can have a feature to easily redo as well.
79 (other comment)
Merge master branch by updating newly introduced Remark feature to include long-form "--remark" prefix in CliSyntax.
80 (other comment)
As per previous discussion, this GUI design will be phased out in favor of Event cards (see commit 02452dd).
Part of the reason includes: (1) lack of horizontal real estate, (2) not a critical feature (selection of tags will be supported by commands in the upcoming PR #116).
81 (other comment)
Depends on which we choose to implement. The alternative, with perhaps the flag --exact, is also viable.
82 (other comment)
Even if decide to keep it as exact by default, i think would be good to minimally make it non case-sensitive.
Yes, exact is already case-insensitive.
83 (other comment)
Changed default behavior to partial matching as requested by @garyljj.
84 (other comment)
Should filtering by "people who do not have a birthday specified" be implemented as well? From the perspective of the welfare IC, they might be interested to check for people whose birthdays are not yet populated, so that they know to approach them for this additional detail.
85 (other comment)
LGTM
86 (other comment)
Are we going to throw error if the user types in wrong specifications? like eg.
list -partialorlist partialorlist Bernice. Currently if i'm not wrong it just ignores and lists all people in the addressbook
Thanks for spotting the bugs, you're absolutely right! At first was thinking of making space for the discussed list 1 3 syntax, but that's not the scope of this PR. Have added changes to check for the required empty preamble.
Some notes:
list -partial and the other variants above are now invalid.
list -partial -n john will not be valid since the preamble -partial exists.
list -n john -partial will be valid since the search term for name is now john -partial.
This issue cannot be avoided since this is fundamentally how the parser is designed, to only parse specified prefixes.
One way is to enforce regex validation, but we probably can't predict how people name themselves / their kids 😂
87 (other comment)
Just need to update HelpCommand.java
then LGTM
Great catch, thanks! Let's defer this till once the list functionality is complete, since there are more pending changes to the command.
88 (other comment)
Reopening this, issue still persists from https://github.com/AY2021S2-CS2103-W16-3/tp/pull/107.
89 (other comment)
Currently only allows deletion of 1 tag at a go (only the last specified tag will be deleted).
eg.
edit --remove -t friends -t colleagueswill removecolleaguestags from all listed persons. Should we allow deletion of multiple tags at a go?
Technically the proposal does specify multiple tag removal, but the syntax didn't reflect it :p
If implementing, can use argMultimap.getValues in line 92 of EditCommandParser.java.
If not implementing, might be better if we change the success message to include which tag was removed.
90 (other comment)
Did we conclude whether we wanted to do this, the other time we had a discussion?
91 (other comment)
Do we want to allow sorting based on multiple conditions? eg. I have 2 people of the same birthday and I want to sort based on ascending name then descending birthday. If we do not want to allow it then should we throw an error when a person inputs more than 1
-s?
Probably not, since it increases the complexity of the command + the parser doesn't distinguish the absolute positions of the prefixes, so matching two prefixes will be a pain.
Throwing error is one way, and the easy way out other way would be to simply document this behavior feature (i.e. only the last sort prefix given is used), just like for the add command. Which do you prefer?
92 (other comment)
I think we agreed that memory not really a concern atm since undo history doesnt carry over across sessions.
Floating an idea, what about (1) setting undo history to a cap higher than the average number of commands used in a single session, and (2) letting undo history carry over sessions? It's a little like vim's swap files.
Validation of the swap history can be achieved by storing the latest address book state in a lightweight hashed format, so it avoids users abusing the swap file to trigger invalid undos.
93 (other comment)
Do we want to allow sorting based on multiple conditions? eg. I have 2 people of the same birthday and I want to sort based on ascending name then descending birthday. If we do not want to allow it then should we throw an error when a person inputs more than 1
-s?
On that note, forgot to mention that if this is desired, there is a workaround for it, e.g. to sort by ascending birthday, and descending name if same birthday, can call these two commands in succession:
list [...] [-s name] -o descending
list [...] -s birthday [-o ascending]
94 (other comment)
I agree, though I also think the UserGuide is a good starting point for the users. Perhaps we can consider link drop in the result pane when help command is called.
On the same note, I think a nice feature would be to remove the menubar feature. Takes up much needed real estate only 😜
95 (other comment)
Gave a cursory glance (no computer to test), looks okay. Note the date comparisons are a little different between EventDate and Birthday:
EventDate should be sorted by date including the year, whereas Birthday is by month and day only. The compareTo method in Date should implement the absolute ordering, and Birthday to override this behaviour using getMonthDayString.
When merging #126, the retrieval of the string date for comparison should return "" for empty Dates. This is noted in the PR description.
96 (other comment)
--any is not the opposite of --exact functionality
97 (other comment)
Tested using #176 head. Very straightforward LGTM.
Dark theme:
Pastel theme:
98 (other comment)
As per internal discussion, will not be implementing due to lack of potential usage.
99 (other comment)
Great suggestions! All proposed changes have been integrated.
100 (other comment)
Not implementing, since #163 already removes all such updates.
101 (other comment)
Already fixed in #145, in previous milestone.
102 (other comment)
Did a quick field test (Person 1 has no fields, Person 2 has all fields populated), most issues from previous PR fixed.
Very nicely implemented! Note certain behaviors below that might need to take a relook (either in same PR, or in a subsequent PR if there is sufficient buffer).
✔️ edit 1 --address TAB -> edit 1 -a
✔️ edit 1 -r -r hey -r hi TAB -> edit 1 -r hey -r hi ENTER -> change remark to "hi"
❗ edit 2 -n -r -e -a -p -b TAB -> edit 2 -n NAME -r REMARK -e EMAIL -a ADDRESS -p -b BIRTHDAY
❗ edit 2 -p 999 TAB -> edit 2 -p
✔️ edit 2 -t hello TAB -> edit 2 -t hello -t TAG1 -t TAG2
hello).❓ edit 1 -t TAB -> edit 1 TAB -> edit 1
❓ edit 2 -t TAB -> edit 2 -t TAG1 -t TAG2 TAB -> edit 2 -t TAG1 -t TAG2
list TAB throws "Invalid command format". Upon invalid command/prefixes, should it ignore as well?edit -r hey TAB / edit 2 -test throws "Invalid command format". Perhaps would be good to state "autocompletion requires command format edit INDEX and remark prefix -r to be specified.103 (other comment)
Tested, LGTM. Note that the current behavior for delete -t tag1 -t tag2 removes people if they at least contain both tag1 and tag2. Intended behavior, will need to document.
104 (other comment)
Seconding this, @nickyfoo. This is a pretty urgent feature, for undoing changes to events.
Redo is a secondary feature, since there is already a command history.
105 (other comment)
Tested, works well. Note the cosmetic issue:
106 (other comment)
LGTM. See #184 for extension.
107 (other comment)
Very quick fix, LGTM.
108 (other comment)
Tested, works well. LGTM.
109 (other comment)
Tested, works fantastic. Other than @Ellevy's comments on supporting event names, LGTM.
edit 1 -t TAB -> edit 2 -t TAG1 TAB -> edit 2 -t TAG1 -tThere is an extra -t popping out with every second autocomplete pass. Can either raise bug report, or document as a feature.
edit 2 -test TAB -> "Index not specified!"
Error message can be more appropriately phrased as "Index / prefix not specified"
110 (other comment)
Made changes to upcoming event sort as discussed with @Ellevy and @garyljj, i.e. upcoming but done events are also funnelled to the back of the event list, sorted in chronological order with the rest.
111 (other comment)
Very cleanly done, LGTM.
The success message for both number of people and tags is a little weird (the former introduced by me...). Might want to update the result message in a subsequent PR.
112 (other comment)
Completed with merged PRs:
#192 (tags -> list)
#158 (delete by tag)
#128 (remove tags)
#116 (find -> list filtering)
#113 (delete filtered, deprecate clear)
#111 (long form prefixes).
Did not implement delete as alias to list command due to unnecessary complexity.
113 (other comment)
tags command deprecated with #192.
114 (other comment)
Not implementing, for two reasons:
Normal use case will not involve removal of fields (objective of welfare IC is to populate as many fields as possible)
Erroneous field additions are foreseen to be typically corrected during the same session, which is the responsibility of undo
115 (other comment)
Should the KeyCombination event handling fall under the same handleUserKey method? They seem to conceptually belong together.
116 (other comment)
Weird spurious merge conflicts, changes taken directly from branch instead.
117 (other comment)
Was actually on this similar documentation.
118 (other comment)
LGTM.
Was wondering if changing Tag::isString() to remove the square brackets directly would be a good alternative. I haven't seen the brackets during normal use.
119 (other comment)
Weird result message when sorting criteria not stated.
120 (other comment)
Potentially buggy implementation? Will need to fix, perhaps in v1.4.
121 (other comment)
LGTM
@weixue123 (28 comments)1 (commented on others PR)
Need to update the documentation here
2 (commented on others PR)
Update documentation
3 (commented on others PR)
Add a vertical spacing here? - the auto-formatter should take care of this
Same issue with ManufactureDate, CompletedDate and OrderDate
4 (commented on others PR)
If Order has a cheeseType property, then I would assume that one order should only have one type of cheese. Then, I think there should be some checks to ensure this?
An alternative would be to let an Order have multiple cheese types. If so, then we will have to remove the cheeseType property.
5 (commented on others PR)
Update documentation
6 (commented on others PR)
Add documentation
7 (commented on others PR)
Is this class used anywhere yet?
8 (commented on others PR)
I believe these should be placed under testutil instead (not logic/commands/CommandTestUtil.
Also, it will be great if we tested invalid dates and cheese types as well.
9 (commented on others PR)
Standardize all comments to start with capital letter?
10 (commented on others PR)
Should we rename FindCommandParser to FindCustomerCommandParser? In order to be consistent
11 (commented on others PR)
Currently some funny things are happening to the customer list after we make the findcustomer command with an empty field following a valid prefix, for example, after inputting "findcustomer n/".
Perhaps we can consider using ParseException to handle the above case as well?
12 (commented on others PR)
I think we should have two cheeseIds in this completed order? Since its quantity is 2 and we should not have been able to complete it with only one cheese.
Changing the quantity to 1 will work too
13 (commented on others PR)
I think we need to account for the case where the input cheeseId no longer exist.
For example, suppose we have order with OrderId 3 that has been fulfilled with cheese with CheeseId 3.
The user first deletes the cheese with CheeseId 3.
The user proceeds deletes the order with OrderId 3, which brings us to the code block above.
The above for-loop is unable to find the cheese with ID 3, since it has been deleted previously.
this.targetIndex is set to Index.fromZeroBased(1), the default value.
The wrong cheese is deleted.
14 (commented on others PR)
I think we should "unfilter" the order list here? That is, calling model.updateFilteredOrderList(PREDICATE_SHOW_ALL_ORDERS). This is so that we can iterate through the complete order list when finding orders to cascade-delete.
This is so that when the findorders feature is implemented in the future (which will cause the order list to potentially be incomplete), this command can still work fine.
15 (commented on others PR)
Think we can "unfilter" the cheese list here before iterating through it! Rationale below (in another comment).
16 (commented on others PR)
We might not be able to use Index.fromZerobased(0) as the base case representing that a cheese is not found.
In the below for loop, if the matching cheese is in index 0, then we will need to use Index.fromZeroBased(0) as the targetIndex.
So, need to either change the base case or the loop below.
17 (commented on others PR)
The two ways when handling invalid data file:
Data file not in correct format -> warning -> start with an empty address book.
Data file not in correct format -> IllegalArgumentException -> app does not start.
Should we standardize this to one method??
18 (commented on others PR)
I think we can add in a case to handle when the user keys in an expiry date but not a maturity date when adding a cheese.
Anyway, since we are at this topic: I was thinking, we may want to consider dropping certain attributes from the models. For example only, since we have only 1 week left to add features, I think we may not have the time to implement features that deal with the cheeses' manufacture date, maturity date, etc.
We can always leave the clean up to v1.4, so it's just something to think about now? Should discuss more during Saturday's meeting.
19 (commented on others PR)
I think it's okay if the cheese ID does not currently exist?
Consider the following scenario:
User adds a new cheese (CheeseID = 1, CheeseType = Gouda, Quantity = 1)
User adds a new order (OrderID = 1, CheeseType = Gouda, Quantity = 1)
User completes Order 1 with Cheese 1.
User deletes Cheese 1 (we currently allow this to happen without changing the order to which the cheese was assigned).
User close the app.
User reopens the app and runs into an IllegalArgumentException because CheeseID 1 no longer exist.
20 (commented on others PR)
We can also check to ensure that an incomplete order's cheeseIds is empty.
If not, the app can start without errors or warnings even when there's an order in the data file like this:
21 (commented on others PR)
I think disallowing cheese deletion after it has been assigned sounds good - it will be just like IRL where you can't throw away a cheese after assigning it to an order, for example.
22 (commented on others PR)
This one you and Li Quan can decide? or you want to wait until Saturday to discuss also can.
And then, actually a cheese manufacture date don't necessarily have to be after an order's order date right? Are you referring to the order's completed date instead? If so then sounds good!
23 (commented on others PR)
kk
24 (commented on others PR)
I think this line of documentation regarding tags doesn't apply to EditCheeseCommand?
25 (commented on others PR)
I think the parameter name should be editCheeseDescriptor??
26 (commented on others PR)
Should PREFIX_CHEESE_TYPE, PREFIX_QUANTITY and PREFIX_PHONE be in square brackets too? Since they are optional
27 (commented on others PR)
Same issue with doc here!
28 (commented on others PR)
Do also update the UG and the DG (use cases)
29 (commented on own PR)
Okay i just removed the bolding entirely, thought it was unnecessary (dk why I typed it this way, must have missed it).
30 (commented on own PR)
done!
31 (commented on own PR)
ahh I get what you mean. Made the change
32 (commented on own PR)
It's quite hard to make changes to the UI and test them in this current branch, the reason being we cannot yet create observable lists of orders or cheeses.
Is it okay to merge this branch first? Then I can create another branch, rebase on the new storage branch and work on the UI right away.
33 (commented on own PR)
Ignore last ^. I'll rebase on the new storage management branch and work from there.
34 (commented on own PR)
Noted, will address this before tmr (monday) morning
35 (commented on own PR)
Noted, will address this before tmr (monday) morning. Will probably be adding a class to Model to reflect the screens to show.
36 (commented on own PR)
mb, fixed liao
37 (commented on own PR)
mb, forgot to change the methods' and variables' names after copy-pasting - fixed
38 (other comment)
loooks good to me!
@lirc572 (28 comments)1 (commented on others PR)
extra space before />
2 (commented on others PR)
Is the space intended to be there?
3 (commented on others PR)
Missing space
4 (commented on others PR)
Why call it ProjectsFolder instead of something like ProjectList?
5 (commented on others PR)
Extra quotation marks?
6 (commented on others PR)
here can perhaps use Project.addEvent()? since it does not seem to be used anywhere
7 (commented on others PR)
This is not a problem with the test but I think we should put project name instead of project is the message?
8 (commented on others PR)
Perhaps we can change all occurences of Index.fromOneBased(1) to INDEX_FIRST in this file?
9 (commented on others PR)
To be consistent, 1 should not be bold
10 (commented on others PR)
Perhaps it is better to put this under a level 3 heading named others or something? It looks a bit strange to me to have a level 4 heading parallel with level 3 headings.
11 (commented on others PR)
According to seedu md standard, we should put an empty line after each heading:
12 (commented on others PR)
same here
13 (commented on others PR)
same here
14 (commented on others PR)
same here
15 (commented on others PR)
same here
16 (commented on others PR)
same here
17 (commented on others PR)
same here
18 (commented on others PR)
same here
19 (commented on others PR)
same here
20 (commented on others PR)
same here
21 (commented on others PR)
same here
22 (commented on others PR)
same here
23 (commented on others PR)
same here
24 (commented on others PR)
same here
25 (commented on others PR)
same here
26 (commented on others PR)
same here
27 (commented on others PR)
Should this be Contact List instead since we have only one such list?
28 (commented on others PR)
Yes! That would be nice!
29 (commented on own PR)
My bad, forgot to change this line after copying from the sample.
30 (other comment)
@samuelfangjw Changed as requested!
31 (other comment)
General hashcode contract states that
When hashcode is called repeatedly on an object, should return same result unless object has been modified.
Two objects that are equal (according to equals method) should return the same hashcode
Different objects do not have to return the same hashcode, although it's good if it does so.
Wah I never knew there is such a contract. Will do it tomorrow!
For the third point I think it should be the other way round. Objects that are not equal should return different hashcodes as far as possible.
I think it should still be pretty safe to check for different hashcodes for different objects since it should be quite unlikely to collide. Do you think we should remove this check?
@nhzaci (27 comments)1 (commented on others PR)
You might want to consider removing this portfolio line that is a placeholder.
2 (commented on others PR)
You might want to consider following the syntax for writing command line arguments here. In this case, the format should look something like week {WEEK_NUMBER | first | next | prev | last}
3 (commented on others PR)
You could consider changing this to say week 2 shows the second week of the year.
4 (commented on others PR)
You could also consider using the amended week syntax above here as well.
5 (commented on others PR)
For these two lines, please include P / E respectively in the indices for the delete command
6 (commented on others PR)
You might want to review this merge conflict...
7 (commented on others PR)
Please remove the backup folder from your pull request as well.
8 (commented on others PR)
There's another merge conflict marker here as well you might want to fix this
9 (commented on others PR)
This is also another merge conflict marker
10 (commented on others PR)
You might want to remove this as well
11 (commented on others PR)
You might want to delete the .backup file as well
12 (commented on others PR)
Here's the end of the merge conflict marker, you're supposed to tell them which one you want to marge in because Github couldn't do this automatically
13 (commented on others PR)
You might want to remove this portfolio link since it links to an empty file
14 (commented on others PR)
You might want to add a comment on why this part is commented out.
15 (commented on others PR)
Might want to change to EventBook here
16 (commented on others PR)
EventBook*
17 (commented on others PR)
Similarly, you might want to consider leaving a comment on top of this commented chunk
18 (commented on others PR)
You might want to consider removing the comment since you're done implementing it
19 (commented on others PR)
You might want to consider changing the variable name to BACKLOG_EVENT_STATUS
20 (commented on others PR)
You might want to consider changing the name of this to IN_PROGRESS_EVENT_STATUS
21 (commented on others PR)
InProgressCommand**
22 (commented on others PR)
BacklogCommand**
23 (commented on others PR)
Event should be edited based on their identifier, not their index.
Event getEventByIdentifier(int identifier, List<Event> events) throws CommandException {
List<Event> eventsFilteredByIdentifier = events.stream()
.filter(event -> event.getIdentifier() == identifier)
.collect(Collectors.toList());
if (eventsFilteredByIdentifier.size() > 0) {
return eventsFilteredByIdentifier.get(0);
} else {
throw new CommandException(Messages.MESSAGE_INVALID_EVENT_DISPLAYED_IDENTIFIER);
}
}
24 (commented on others PR)
You might want to consider converting the user input to uppercase as well, since currently, if user passes in s/todo, this would get rejected as they would need to do s/TODO, which might not be very good UX.
If we uppercase the user input, then the user can pass in s/tOdO and it will still work.
25 (commented on others PR)
You might want to consider renaming index to identifier, since we would be checking by identifier, instead of index.
26 (commented on others PR)
You could consider renaming these to Identifier instead of Index
27 (commented on others PR)
You could consider renaming it to Identifier
28 (other comment)
Closed due to cyclic dependency
29 (other comment)
Closes #71
30 (other comment)
Closes #49
@kumsssss (27 comments)1 (commented on others PR)
could change contacts to household items
2 (commented on others PR)
I also think it should be changed back to VALID_NAME_AMY for now just for consistency.
3 (commented on others PR)
Since this test is a returnsFalse, maybe you shouldn't include an assertTrue inside. Perhaps you could write that in a separate method?
4 (commented on others PR)
Maybe warning can be in all caps?
5 (commented on others PR)
U could try using assert throw like in the test right below this. U could also specify what the Exception you are throwing actually is.
6 (commented on others PR)
Could add some tests since you removed these 😃
7 (commented on others PR)
I think u can use the above two lines to print the number of items listed. One has the s in items while the other doesn't to differentiate between single and multiple items being returned.
8 (commented on others PR)
maybe you could say within the next 7 days instead of in 7 days.
9 (commented on others PR)
similar to the previous one, maybe you could say expiring within the next 2 weeks
10 (commented on others PR)
u could try using equalsIgnoreCase() like I did for sortCommand
11 (commented on others PR)
I feel it should be StoreMando since we referring to our app.
12 (commented on others PR)
The table still displays fine right??
13 (commented on others PR)
Should these be like UniqueItemList instead of UniquePersonList? Maybe can change this in the future.
14 (commented on others PR)
I think we can just delete this file also right? If not, can just remove the Level 3
15 (commented on others PR)
What does this look like?
16 (commented on others PR)
I think can change this back.
17 (commented on others PR)
Can just delete the test. Don't need to comment it out
18 (commented on others PR)
"User wants to search" or "User searches" maybe? Instead of saying expiring soon, can say expiring within the next 7 days or next 2 weeks?
19 (commented on others PR)
should be 3a right?
20 (commented on others PR)
same for this
21 (commented on others PR)
it should be 1b for this i think
22 (commented on others PR)
can change this back to location? thx!
23 (commented on others PR)
if user keys in command "clear", will he get the message "All items in the specified location (if any) are cleared"? Personally, i feel like it should say "Inventory has been cleared".
24 (commented on others PR)
i think this won't work if item location is like "Kums room" and the command is "clear Kums room". Maybe you can try it out and see if it works.
25 (commented on others PR)
the item location has a lot of white spaces in between Kums and room.
26 (commented on others PR)
Should a test be added for this?
27 (commented on others PR)
can add same expiry date also just to make it clearer.
28 (commented on own PR)
I felt like the VALIDATION_REGEX does not help to check if the date given by the user is a valid date. So, I used LocalDate instead to check if the date is valid, which can be seen in the subsequent lines. Hope this clears things.
29 (commented on own PR)
I will add it back. expiryDate will not be null anymore.
30 (commented on own PR)
I chose to do it this way as I cannot guarantee Long.parseLong(test) will not throw a NumberFormatException. So, I made sure test is made of digits before I check if it is a non-zero value.
31 (commented on own PR)
Ok. Changed as stated.
32 (commented on own PR)
alright!
33 (commented on own PR)
ohh ok i get it. I'll change it. Thanks!
34 (commented on own PR)
Oh yea I'll remove it! Thanks!
35 (commented on own PR)
alright will change it!
36 (commented on own PR)
oh yea my bad
37 (commented on own PR)
sure will do!
38 (commented on own PR)
ok will change it
39 (commented on own PR)
if I'm not wrong, it only takes in days and weeks as TIME_UNIT. I just went to check the reminderCommandParser. I think we can leave it as it is now and change later if we make changes to the feature.
40 (commented on own PR)
alright will do so!
41 (commented on own PR)
ok!
42 (commented on own PR)
yes it will still work
43 (commented on own PR)
alright will do so!
44 (commented on own PR)
ok will make the changes
@chewterence (27 comments)1 (commented on others PR)
Should this be edited or removed?
2 (commented on others PR)
Perhaps the responsibilities for each member should be updated?
3 (commented on others PR)
should we have an overloaded constructor?
4 (commented on others PR)
perhaps this method may seem a little too long? maybe we could use a stream here
5 (commented on others PR)
what is the difference between passenger and commuter?
6 (commented on others PR)
Is this method meant to be person?
7 (commented on others PR)
did you mean stub?
8 (commented on others PR)
did you mean stub?
9 (commented on others PR)
i noticed the same potential problem in the rest of the code
10 (commented on others PR)
small thing but, perhaps this could be renamed getTripDayAsString() as we have discussed
11 (commented on others PR)
small thing but, perhaps this could be renamed getTripTimeAsString() as we have discussed
12 (commented on others PR)
perhaps we should call TripDay and TripTime's source.getTripDayAsString() method so as to not violate the law of demeter?
13 (commented on others PR)
should these be the actual values in the native types?
or should these be the strings, because i believe command test util is to test the input that the user puts in (in the form of a string). To test if it is correct or wrong input
14 (commented on others PR)
this is ok because its testing the constructor, not the command
15 (commented on others PR)
this is ok because its testing the .equals method, not the command
16 (commented on others PR)
i believe this should be ok, because its for the purpose of constructing a passenger
17 (commented on others PR)
Did you mean this or is it a typo?: "@code Passenger}s"
18 (commented on others PR)
did you mean the phone number to verify? not name.
19 (commented on others PR)
what do you mean by "the name as a phone?"
20 (commented on others PR)
did you mean "phone number"
21 (commented on others PR)
i noticed the same problem as phone here.
22 (commented on others PR)
i noticed the same problem as phone here.
23 (commented on others PR)
i noticed the same problem as phone here.
24 (commented on others PR)
i noticed the same problem as phone here.
25 (commented on others PR)
perhaps you could add a fullstop here
26 (commented on others PR)
fullstop here too
27 (commented on others PR)
perhaps a fullstop here too
28 (commented on own PR)
rectified
29 (commented on own PR)
thanks, i have rectified this issue.
30 (other comment)
LGTM 👍 Closes #5
31 (other comment)
LGTM 👍
32 (other comment)
Resolves issue #57
33 (other comment)
34 (other comment)
Update methods to not violate law of demeter
35 (other comment)
PR #121 resolves the issue with unpool command working with the updated model
36 (other comment)
issue resolved with #128
37 (other comment)
#121 resolves this issue after model is updated with poolList
38 (other comment)
issue resolved with #111 as overloaded constructor inside person class is no longer required
39 (other comment)
issue is now closed because we have decided not to implement this feature, but rather another feature.
@jlxw48 (27 comments)1 (commented on others PR)
maybe block letters? follow the format of the other fields
2 (commented on others PR)
maybe block letters? follow the format of the other fields
3 (commented on others PR)
can consider removing the extra blank line?
4 (commented on others PR)
I think this JavaDoc comment can be further refined.
5 (commented on others PR)
Can I check why you think it is better to not differentiate code/command line keywords from normal words in a sentence?
6 (commented on others PR)
Would it be better to display all the possible parameters?
7 (commented on others PR)
Do you think it would be better to give the user instructions on how to initialise/use our application? Or are there reasons why you think this should not be here?
8 (commented on others PR)
Could you check if there is an & delimiter for the subsequent keywords?
9 (commented on others PR)
Would it be clearer to the user if we used markdown to format the keywords here too?
10 (commented on others PR)
Do you think a person should have a tag describing a policy if s/he has no policy number?
11 (commented on others PR)
Do you think it would be more consistent if you ended this line with a fullstop, just like the above lines?
12 (commented on others PR)
Do you think we can use more suitable tags given the insurance agent-client relationship?
13 (commented on others PR)
Would it be more consistent if the policy number format followed that from above? It is not very consistent with the policy number formats written in the Quick Start section, and the Features > Add section (there are 2 different formats in 3 different sections).
Also, there is a spelling mistake for the t/premiunplan. Do be more careful next time!
14 (commented on others PR)
Do you think it would be good to clarify on the maximum number of flags that can be used in each command execution?
15 (commented on others PR)
As Yong Shen has suggested in my PR, do you think it would be be more intuitive to the user if we rename policies as insurance policies instead, so that the 'i' flag is more suitable?
16 (commented on others PR)
I was wondering if it would be good to clarify if a keyword is bounded by '&' delimiters (if any)? Else, some users might think that keywords are words and mistake a search for 'Hans Bo' to return the same as 'Hans & Bo'.
17 (commented on others PR)
As in the above comment, perhaps we can add in an example where we should find alex david to show the difference between the 2 types.
18 (commented on others PR)
Just something minor: would be good if in our documentation we can clarify that our search is case insensitive.
19 (commented on others PR)
Would it be clearer if the regex was stored as a constant so that another developer would better understand what you are trying to split by?
20 (commented on others PR)
I realised that this List>String> is used in all the subclasses. Perhaps we can consider shifting it to the parent class in the future?
21 (commented on others PR)
Just to check, this test checks if the address contains "12345", "alice@gmail.com" or "Alice" right? If so, perhaps it would be better to clarify that the person's address does not contain any of these keywords and thus the match fails? Else, it seems like we are testing for all the fields mentioned.
22 (commented on others PR)
Same comment as the other file!
23 (commented on others PR)
I like that this is so succinct, but others who are less proficient/new to Java might find this hard to digest, since it condenses a few steps into one. Do you want to consider writingn this on separate lines?
24 (commented on others PR)
Do you think it would be more readable if these two strings are abstracted to static final variables?
25 (commented on others PR)
Do you think it would be more appropriate to name the test to describe that you are testing reapeated unlocks/mutability rather than just "equals"?
26 (commented on others PR)
Would it be more appropriate to name this variable POLICY_ID_CONTAINS_ANGULAR_BRACKETS rather than POLICY_ID_CONTAINS_CARROT? Since carrot can refer to ^ too.
27 (commented on others PR)
If I'm not wrong the # symbol is placed after a class name to show that the method following the # belongs to a class. Perhaps it might be clearer to do so such that other developers will know where to find this method?
28 (commented on own PR)
I was thinking that it would be better to link to the User Guide itself. Perhaps I should change the description of the URL. Or would it be better to directly link to Quick Start?
29 (commented on own PR)
Great suggestion! Thanks!
30 (commented on own PR)
I was thinking if I name it getPolicyUrl, another developer might mistake it to return a String rather than an Optional. What do you think?
31 (commented on own PR)
Good point. I've changed it!
32 (commented on own PR)
Good point, I didn't notice that.
33 (commented on own PR)
Each new line is meant to separate the logic from the other lines, so that each "section" gives me 1 variable/object that I would eventually pass into the assert function. I felt that it looks cleaner that way. What do you think?
34 (commented on own PR)
Okay, thank you!
35 (commented on own PR)
How should we define it actually? I was thinking the same thing, but couldn't think of how to define it properly.
36 (commented on own PR)
Okay, changed!
37 (commented on own PR)
Okay, I changed the positive integer line to the following:
Is this clearer?
38 (commented on own PR)
Okay, added!
39 (commented on own PR)
Okay, added!
40 (commented on own PR)
Okay, added.
41 (commented on own PR)
Hmm okay, I think I will be adding a section to talk about the fields that can be added for each contact.
42 (commented on own PR)
Thanks for spotting this!
43 (commented on own PR)
Can you clarify what you mean by this?
44 (commented on own PR)
Okay yes, thanks!
45 (commented on own PR)
FLAG uses the identifier of each attribute to help the program identify which attribute you are referring to.
For more information about the identifiers for each attribute, refer to What information can we store for each client contact?.
Added the above 2 statements, hope they make things clearer.
46 (commented on own PR)
Okay, I've added the below 2 statements for clarity:
The data file is stored in a zip file inside the data folder in the same folder.
If you previously set a lock for ClientBook, the zip folder can be unzipped with that same password.
47 (other comment)
I will be doing the test for the new command in the next iteration.
@yaowei-soc (24 comments)1 (commented on others PR)
Trailing white space
2 (commented on others PR)
Trailing white space
3 (commented on others PR)
!aliasesOptional.isPresent() -> aliasesOptional.isEmpty()
4 (commented on others PR)
Might want to follow the addressbook initialization
initialAddressBookData = addressBookOptional.orElseGet(SampleDataUtil::getSampleAddressBook);
initialAliasesData = aliasesOptional.orElseGet(SampleDataUtil::getSampleAliases);
5 (commented on others PR)
Missing javadoc for aliases param
6 (commented on others PR)
Should we document this unchecked exception?
7 (commented on others PR)
Should we document this unchecked exception?
8 (commented on others PR)
!jsonAliases.isPresent() -> jsonAliases.isEmpty()
9 (commented on others PR)
Return value of parseTagsExceptLast not being used and Javadoc missing. May want to consider returning void?
References found in:
AddCommandParser#L100
EditCommandParser#L129
10 (commented on others PR)
Will need to add PREFIX_REMARKS from PR #77
11 (commented on others PR)
Duplicate chunk found in AddCommandParser#L84-105, may want to refactor it out?
12 (commented on others PR)
Can be replaced with positions.sort(Comparator.comparingInt(PrefixPosition::getStartPosition));
13 (commented on others PR)
Can make aliases final
14 (commented on others PR)
May want to make the happy path prominent: https://nus-cs2103-ay2021s2.github.io/website/se-book-adapted/chapters/codeQuality.html#make-the-happy-path-prominent
if (helpWindow.isShowing()) {
helpWindow.focus();
} else {
helpWindow.show();
}
15 (commented on others PR)
Sure!
16 (commented on others PR)
Got it, maybe later on we can implement a sample alias in
17 (commented on others PR)
18 (commented on others PR)
Should be LogsCenter.getLogger(getClass());
19 (commented on others PR)
input is not used
20 (commented on others PR)
Should this test be ensuring that all items in the list starts with 'a' rather than just index 0?
21 (commented on others PR)
Might want to test to make sure that empty spaces returns an empty list:
[null, ""]: non empty list
[" ", " ", " "]: white spaces return empty list (is this the intended behaviour?)
["e", "ex", ...]: non empty list
I've also realised that the method getAutocompleteCommands in Logic.java isn't documented.
22 (commented on others PR)
Slight typo here. Other than that, LGTM.
23 (commented on others PR)
Why is there empty line here?
24 (commented on others PR)
Any reason why you decided to keep a List and Map instead of converting the map to List?
25 (commented on own PR)
I accidentally added this duplicate @ ce88d0f01172233e0097c0b35f3d39f32c7a4180
26 (commented on own PR)
Ah yes, it should be true if it will be shown and false if it should be hidden.
What do you think of rephrasing it like this:
/**
* Returns predicate that determines field control visibility.
* @return predicate that returns true if prefix linked control should be shown
*/
27 (commented on own PR)
Added more test cases @ 1e159f4e080ebf9107aa3e93e24bb7c8b32d70a2
28 (commented on own PR)
Added more test cases @ 1e159f4e080ebf9107aa3e93e24bb7c8b32d70a2
29 (commented on own PR)
This line should be checking for same object
@Test
public void test_predicateEqualsCheck_allEquals() {
...
assertEquals(addressArgs, addressArgs);
...
30 (other comment)
LGTM, but perhaps might want to rename PR to something more appropriate. See #52
31 (other comment)
Git Commit Name Convention
We will stick to conventional commit style, but we will capitalize the first letter after the colon.
Recommended examples:
The general consensus is that if it conveys what this commit does, it's fine.
Git Branch Naming
Naming of the branch doesn't really matter as long as it makes sense.
https://se-education.org/guides/conventions/git.html
If a branch is related to an issue, it is recommended to use the format {issue number}-some-keywords-from-the-issue
Recommended examples:
docs/69-update-readme
feature/22-add-storage-backup
Pull Request Naming Convention
No specific PR naming convention, as long as it conveys information on what that PR does.
Can use conventional commit style or write your own short description.
32 (other comment)
Seems like the changes in PR #65 are working. I have closed the v1.1 milestone since there's no more issues related to it.
33 (other comment)
In ModelManager, should line 107
updateFilteredPersonList(PREDICATE_SHOW_ALL_PERSONS);of
public void addPerson(Person person)method
be updated/removed to ensure the filter is persistent even after adding a person?
Other than this, everything else LGTM for
Logiccomponent.
This line should not affect the filter after adding a new person
34 (other comment)
I realised that the help text for add command does not include spaces between the flag and the value. I'm guessing the edit command will have this issue too
35 (other comment)
Sort order for list changed after doing a find command. Should list command show the original order?
36 (other comment)
@oeiyiping will you be updating the diagrams for your changes to Remarks?
37 (other comment)
https://github.com/AY2021S2-CS2103T-T12-3/tp/pull/108
Seems like the config still doesn't work well. Might want to disable codecov/patch
38 (other comment)
JAR released: https://github.com/AY2021S2-CS2103T-T12-3/tp/releases/tag/v1.2.1
39 (other comment)
Fixed in https://github.com/AY2021S2-CS2103T-T12-3/tp/pull/121
40 (other comment)
@justgnohUG are you taking this issue? Seems like it is related to #124
41 (other comment)
Since everyone has already updated their section of the DG for week 10, I'm closing this issue.
You can check your tP progress here: https://nus-cs2103-ay2021s2.github.io/dashboards/contents/tp-progress.html
42 (other comment)
Closing issue since it is implemented in PR #121
43 (other comment)
@darkdestry-t have you completed the assertions? https://nus-cs2103-ay2021s2.github.io/dashboards/contents/tp-progress.html
@yhtMinceraft1010X (23 comments)1 (commented on others PR)
For LICENSE, there's no need to change person to task.
2 (commented on others PR)
For README, the AddressBook should not be changed since we are referencing the original.
3 (commented on others PR)
For this one, I think its best to get rid of this line if we don't have a team email.
4 (commented on others PR)
I think we should keep addressbook in this file. The link might break and we're still not sure how DevOps will change from here.
5 (commented on others PR)
Likewise for this one, I'm of the opinion we should keep the addressbook here
6 (commented on others PR)
I think we should delete the tutorial docs from our repo since they are unlikely to have any purpose in the future.
7 (commented on others PR)
I think this unused code block has to be removed.
8 (commented on others PR)
I wouldn't describe sorting as replace task in javadoc.
9 (commented on others PR)
Personally, I prefer to initialise both index and tags in the constructor. But I'll leave it up to you to decide.
10 (commented on others PR)
I don't think all the other prefixes (apart from PREFIX_TAG) are necessary under tokenize method.
11 (commented on others PR)
I think the UG should also mention what happens when the time is not keyed in. E.g. The current time on your computer is taken.
12 (commented on others PR)
I recommend moving this block of code to before editedTask. Avoids unnecessary generation of the editedTask object if there's no tag to delete.
13 (commented on others PR)
Not sure why there is a new Use case 9 right before the NFR section.
14 (commented on others PR)
Nice to see the new commands here. But I think the new mod command for finding by module should be included + the top list of commands and bottom summary should also be updated before the UG update is complete
15 (commented on others PR)
To add on, maybe the valid module criteria should be listed at the top of the UG, before the instructions. But I think it can be added in later.
16 (commented on others PR)
Not sure why there's a minus sign here
17 (commented on others PR)
I see. Sounds good
18 (commented on others PR)
I have a few questions:
Wouldn't the edit command suffice for changing the recurrence of a task?
If we decide to keep the recur command, is there a way to remove recurrence without using edit command? I think users may be confused as to why the way to remove recurrence is not obvious.
19 (commented on others PR)
Actually, for 1, scratch the question. We also have a tag command and edit command that can handle tag changes.
20 (commented on others PR)
If it works, I guess it can be used
21 (commented on others PR)
I think this link can be kept, but it has to be changed back to AddressBook level 4 since that was the original project from which this came out.
22 (commented on others PR)
Same scenario as the one for ModuleCard
23 (commented on others PR)
Looks good, although I think the line for empty recurrence should also mention that the prefix r/ must be kept.
24 (commented on own PR)
To clarify, the module field should be changed to a proper module code?
25 (commented on own PR)
To clarify, is the deadline here supposed to change?
26 (commented on own PR)
I assume here the ADDRESS should be changed to DESCRIPTION. Is there any other changes to make?
27 (commented on own PR)
I was considering using enum but I couldn't get the constructors to work. Maybe I'll look into it in v1.3.
28 (commented on own PR)
I've changed it to show how many tasks there are across all 3 workload ratings for a single module.
29 (commented on own PR)
Just to clarify, it's just re-add the original workload count implementation?
So we have:
-One variable counting how many low workload tasks there are
-One for medium workload tasks
-One for high workload tasks
-One that sums up the workload rating translated to int
30 (other comment)
Pull request closed to avoid accidental merging into the team repo.
31 (other comment)
Pull request closed given that changes are small. All changes are moved to the done status PR
@Jacob-Pang (21 comments)1 (commented on others PR)
The logic flow should be:
IF patientIndex is provided -> user wants to change patient for the appointment {
patient = patient at patientIndex
} else {
patient = same patient from appointment
}
2 (commented on others PR)
Javadoc to update
3 (commented on others PR)
Javadoc to update
4 (commented on others PR)
This one should be getAppointmentSchedule instead
5 (commented on others PR)
Is this supposed to be FindAppointmentCommand.MESSAGE_USAGE instead?
6 (commented on others PR)
There is no need to have a separate try statement.
7 (commented on others PR)
We discussed that we will not need to maintain the email or address of the doctor.
8 (commented on others PR)
There was no need to create a separate class. The methods could fit under SampleDataUtil.
9 (commented on others PR)
The introduced spacing is inconsistent
10 (commented on others PR)
Typo to amend to DoctorRecords
11 (commented on others PR)
It was inside (see a few more lines below). Moved it to group w patient records methods
12 (commented on others PR)
Yes
13 (commented on others PR)
Yes there were repeated same method calls and implementations under the individual PatientRecordsStorage and DoctorRecordsStorage.
14 (commented on others PR)
Nope, should only have changed the storing style in the files
15 (commented on others PR)
It is because the initialised address book is empty here.
Should have one for patients and doctors sorry
16 (commented on others PR)
This was an accident
17 (commented on others PR)
Here is my take on this:
The enum could return the DateTimeFormatters instead,
enum StandardDateTimeFormat {
DATE_SLASH_SHORT ( "dd/MM/yyyy" )
...
private dateTimePattern;
private StandardDateTimeFormat (String dateTimePattern) {
this.dateTimePattern = dateTimePattern;
}
public DateTimeFormatter getDateTimeFormatter() {
return DateTimeFormatter.ofPattern(dateTimePattern);
}
public String getDateTimePattern() {
return dateTimePattern;
}
}
Then, the parsing of the non-Next inputs could be performed like this:
public LocalDateTime parseDateTime (String input) {
for (StandardDateTimeFormat standardDateTimeFormat : StandardDateTimeFormat.values()) {
try {
return LocalDatetime.parse(input, standardDateTimeFormat.getDateTimeFormatter());
} catch (DateTimeParseException e) {
continue; // no need for regex checking because check is performed by LocalDateTime.parse
}
}
throw ParseException(...); // does not conform to any of the standard inputs
}
I really do not recommend having date and time parsed separately, but for discussion sake, one can implement 2 enums, standardDateFormat and standardTimeFormat and the loop can be modified like this:
public LocalDateTime parseDateTime (String input) {
for (StandardDateFormat standardDateFormat : StandardDateFormat.values()) {
for (StandardTimeFormat standardTimeFormat : StandardTimeFormat.values()) {
try {
DateTimeFormatter standardDateTimeFormatter = DateTimeFormatter.ofPattern(
standardDateFormat.getDatePattern() + " " + standardTimeFormat.getTimePattern());
return LocalDatetime.parse(input, standardDateTimeFormatter);
} catch (DateTimeParseException e) {
continue; // no need for regex checking because check is performed by LocalDateTime.parse
}
}
}
throw ParseException(...); // does not conform to any of the standard inputs
}
18 (commented on others PR)
Should equals check for UUID field?
19 (commented on others PR)
The predicate cannot check for keywords in the UUID.
20 (commented on others PR)
The variable pt might be misleading here
21 (commented on others PR)
Is this supposed to be String as per JsonAdaptedPerson
22 (commented on own PR)
Will remove comment, but in order to test doctors too will require another AddressBook>Doctor> as a parameter in the future
23 (commented on own PR)
Separated into 2.
24 (commented on own PR)
Another predicate accepted by the method, NameContainsKeywordsPredicate must be a Predicate>Person>. So cannot change this.
@nowknowing (21 comments)1 (commented on others PR)
Do we keep this? Remarks isn't in our milestone but I suppose we could
2 (commented on others PR)
Should this also be parseStudentCommand?
3 (commented on others PR)
getAddStudentCommand
4 (commented on others PR)
also just curious what is k
5 (commented on others PR)
Should we use the studentIndex-Session index here too?
Actually there's no use of this toString() method currently, right
6 (commented on others PR)
Add session to sth?
7 (commented on others PR)
I guess also do the folder with your name
8 (commented on others PR)
Coming up, will have to edit this to serve Recurring Sessions as well.
TODO for me
9 (commented on others PR)
Im understanding that getPrev3 month is getMonth applied to every student, and for 3 months. I guess it'd be considered less "repeated code" if this method was built on getMonth. possibly using getMonth's methods from within getPrev3?
10 (commented on others PR)
Might be consistent with the other commands if not capitalised. eg "past_fees" / "3_fees" / "3_month_fees"
11 (commented on others PR)
"Shows the totalled fees per month, for the past 3 months." Or something of the sort could be somewhat more accurate.
12 (commented on others PR)
super neat, hadn't thought of putting it at model!
13 (commented on others PR)
MIght be good to mention somewhere its 1-to-1 only
14 (commented on others PR)
1.imo shld mention 1-to-1 here.
2.provide" -> "get"/"receive"/"retrieve"
15 (commented on others PR)
The link here not working on mine
16 (commented on others PR)
As with the following displayed session list
17 (commented on others PR)
This looks like the same thing to me as onSessionDate (but without the assert), with different input.
Perhaps rename both methods to reflect this difference in input, or just let them be overloaded methods
And for the former, call onSessionDate(new SessionDate()) from within
I like you use the word build better than just 'on'
18 (commented on others PR)
Long method. You may want to change filterOneWeekTuitionSession to 3DaysTuitionSession and use the former implementation if that shortens the method.
19 (commented on others PR)
yeah im suggesting you overload the method to allow localDate input
20 (commented on others PR)
i.e.
rename onSessionDate(SessionDate sd) method to buildSessionOnDate(SessionDate sd)
make a
public Session buildSessionOnDate(LocalDate date) {
SessionDate sessionDate = new SessionDate ......
return buildSessionOnDate(sessionDate);
}
21 (commented on others PR)
but i guess not exactly necessary
22 (commented on own PR)
ooh sorry yeah let me just undo the change i simply refactored
23 (commented on own PR)
Right totally forgot. Will do so in coming commit
24 (commented on own PR)
No man trying to solve merge conflicts w copy and paste led to a disaster
25 (commented on own PR)
Will do so in next commit. when plantUML comes alive
26 (commented on own PR)
omg yes sry thanks for pointing out
27 (commented on own PR)
No it's not intended because I didn't (and kind of currently dont) know what problems this may cause.
Not intended as in never questioned it
What problems might this cause/ what recommended way might there be?
Was thinking since its extending Session, the parent's method to access Sesssion contents are inherited
28 (commented on own PR)
no idea myself leemme delete
29 (commented on own PR)
right!
30 (commented on own PR)
yep!
31 (commented on own PR)
Yep thanks. actualy given your comments I think there was also no need for this to be a static method.
Will replace with a .equalTime(SessionDate sessionDate)
32 (commented on own PR)
yep will do this
33 (commented on own PR)
Thanks, did in the coming commit
34 (commented on own PR)
Right ive got to make a RecurringSession json. to save things into if Session instanceOf RecurringSession.
35 (commented on own PR)
Just done so, I think should be working
36 (commented on own PR)
Yeah ive pulled upstream. ChoonWei's method doesn't check for Recurring session so there arent clashes.
Yep will do as a seperate issue
37 (commented on own PR)
Ok found it will fix
38 (commented on own PR)
actually no idea
39 (commented on own PR)
Issue is solved by adding type information in json, as necessary for deserialisation polymorphism.
40 (commented on own PR)
Thanks have added this as a new separate issue
41 (commented on own PR)
ok, in coming commit!
42 (commented on own PR)
no it wasn't wrong. outputs correct either ways because isConsistentDatesAndInterval does the calculation as well.
That ensures days between (date 1, date 2) is >=0
43 (commented on own PR)
but i guess its simpler (less computation) if use startSafter(sessionDate) and more consistent
44 (other comment)
I don't mean readme. i mean't the aboutUs page
45 (other comment)
- There seem to be missing the switch case for
delete_sessioninAddressBookParser.java, which makes the command inexecutable.
- I added the switch case myself locally and tried to execute the command when the student has no sessions, seems to throw an exception,
IndexOutOfBoundsException, which was out of the application. Maybe you could test it and let me know if you face the same issue too?
Other than the above, the rest looks good! thanks!
I think I've fixed it.
Still have issues with building TypicalStudent with StudentBuilder.addSession(). Which is why testCases are commented out.But this at the moment is another matter.
46 (other comment)
Would it be better to integrate the Session class diagram in the Model component? I think it would add more value there instead of being a standalone. (We can show the association with the Student class there)
Also, would it be better to make each feature distinct instead of combining it into "Session" feature to preserve the current formatting?
You are probably right about the Model component; it would be good to be together with Student. I think i'd take SessionClassDiagram out of the DG for now.
About the feature:
I did this because creation then a deletion does not each sound like a different feature (if feature is the word used) rather only difference in the command, which may not even need 2 seq diagrams like there already is, i felt. we shld discuss
@Ellevy (20 comments)1 (commented on others PR)
* `delete -t colleague` deletes the "colleague" tag in contacts that contains this tag. If "colleague" is the only tag that that contact contains, the contact will be deleted.
2 (commented on others PR)
* Delete every person that has only 1 tag which is the given tag.
* If the person is tagged by another tag, only the given tag is removed from the person. The contact will not be deleted.
3 (commented on others PR)
* `delete -t colleague -t cs2103` deletes the "colleague" tag and "cs2103" tag in contacts that contains these tags. If "colleague" and "cs2103" are the only tags that that contact contains, the contact will be deleted.
4 (commented on others PR)
+ "OR delete the person if that person has only 1 tag which is the provided tag\n"
+ "OR remove the provided tag from the person if that person has other tags.\n"
5 (commented on others PR)
Does this mean we should create another command just to handle contact deletion and this delete -t command only deals with tag deletion? Basically similar to our add, find and delete commands that only deal with contacts while tags command only deals with tags.
6 (commented on others PR)
return isDone ? "\u2713" : "";
7 (commented on others PR)
* Tick represents done, empty string represents not done.
8 (commented on others PR)
Suggested changes to the javadocs accordingly, thanks!
9 (commented on others PR)
If I'm not wrong this implementation is the same as the UniquePersonList. Do we want to change? I guess if we change this then we should standardise and change for the UniquePersonList too.
10 (commented on others PR)
Would it be better for us to display another message if the tag specified is not found in the listed persons?
Currently it is "Removed tag from: ". Maybe we can change it to
eg. "This tag does not exist in the persons listed. No tags were removed."
11 (commented on others PR)
* EventDate must contain a year.
12 (commented on others PR)
* Parses input arguments and creates a new EEditCommand object
13 (commented on others PR)
* Parses the given {@code String} of arguments in the context of the EEditCommand
* and returns an EEditCommand object for execution.
14 (commented on others PR)
* Creates and returns an {@code Event} with the details of {@code eventToEdit}
* edited with {@code editEventDescriptor}.
15 (commented on others PR)
* @param index of the event in the filtered event list to edit
16 (commented on others PR)
* Edits the details of an existing event in PartyPlanet.
17 (commented on others PR)
if (xDaysLeft < 0 && yDaysLeft >= 0) {
return 1;
} else if (xDaysLeft >= 0 && yDaysLeft < 0) {
return -1;
} else {
return xDaysLeft.compareTo(yDaysLeft);
}
18 (commented on others PR)
ArgumentTokenizer.tokenize(arguments, PREFIX_NAME, PREFIX_DATE, PREFIX_REMARK);
Probably should include auto complete for name for events since we allow it for persons
19 (commented on others PR)
throw new CommandException(Messages.MESSAGE_INVALID_EVENT_DISPLAYED_INDEX);
20 (commented on others PR)
Map<Prefix, String> prefixMethodMap = Map.of(
PREFIX_NAME, event.getName().fullName,
PREFIX_DATE, event.getEventDate().displayValue,
PREFIX_REMARK, event.getDetails().value
);
21 (other comment)
LGTM
22 (other comment)
LGTM
23 (other comment)
LGTM
24 (other comment)
LGTM
25 (other comment)
Are we going to throw error if the user types in wrong specifications? like eg. list -partial or list partial or list Bernice. Currently if i'm not wrong it just ignores and lists all people in the addressbook
26 (other comment)
LGTM
(On a side note: would be good to implement min height for the event later on too)
27 (other comment)
Currently only allows deletion of 1 tag at a go (only the last specified tag will be deleted).
eg. edit --remove -t friends -t colleagues will remove colleagues tags from all listed persons. Should we allow deletion of multiple tags at a go?
28 (other comment)
Currently only allows deletion of 1 tag at a go (only the last specified tag will be deleted).
eg.
edit --remove -t friends -t colleagueswill removecolleaguestags from all listed persons. Should we allow deletion of multiple tags at a go?
Technically the proposal does specify multiple tag removal, but the syntax didn't reflect it :p
- If implementing, can use
argMultimap.getValuesin line 92 ofEditCommandParser.java.
- If not implementing, might be better if we change the success message to include which tag was removed.
Can possibly also write an error message telling them they can only delete 1 tag at a go
29 (other comment)
Do we want to allow sorting based on multiple conditions? eg. I have 2 people of the same birthday and I want to sort based on ascending name then descending birthday. If we do not want to allow it then should we throw an error when a person inputs more than 1 -s?
30 (other comment)
Do we want to allow sorting based on multiple conditions? eg. I have 2 people of the same birthday and I want to sort based on ascending name then descending birthday. If we do not want to allow it then should we throw an error when a person inputs more than 1
-s?
Probably not, since it increases the complexity of the command + the parser doesn't distinguish the absolute positions of the prefixes, so matching two prefixes will be a pain.
Throwing error is one way, and the ~easy way out~ other way would be to simply document this behavior feature (i.e. only the last sort prefix given is used), just like for the
addcommand. Which do you prefer?
I think documenting is good! Which do you prefer?
31 (other comment)
Do you think its better to include the --exact and --any flag?
eg.
delete --exact -t a -t b deletes all person with tag a AND b
delete --any -t a -t b deletes all person with tag a OR b
might be easier for users and it is consistent with list and elist
32 (other comment)
Currently all successful elist actions display "Listed all events" as the result message. Should we specify them? for eg. "Listed all events in chronological order", or "Listed all events in ascending name order".
For this I believe its the same as list. I guess if want can change but must change for both. Maybe I open an issue for changing the output message for both list and elist to do later on? Then if this one no other issues then can merge first.
33 (other comment)
Hopefully I managed to find all the places to change and allow autocomplete for name to work. Other than that, the rest seems good!
34 (other comment)
Not very sure why but it seems like when I run the app they can't load the fonts. (See pic below)
But the app still runs well with no errors
@jay9645 (20 comments)1 (commented on others PR)
I'm a little confused about why current_password is wrapped in square brackets. Does this mean that if a password has not been set, then unlock command does not need a password?
2 (commented on others PR)
For the return statement of this method, the comments helped me to understand the code easily which is already great, but I was thinking whether the expression would be a little less complicated if you separate the boolean statement into multiple named boolean variables.
For example
@Override
public boolean equals(Object other) {
isSameObject = other == this;
if (isSameObject) {
return true;
} else {
isLockCommandObj = other instanceof LockCommand; // instanceof handles nulls
isCurrentPasswordEqual = currentPassword.equals(((LockCommand) other).currentPassword);
isNewPasswordEqual = newPassword.equals(((LockCommand) other).newPassword);
return isSameObject || (isLockCommandObj && isCurrentPasswordEqual && isNewPasswordEqual);
}
}
3 (commented on others PR)
If we remove the password here, does that mean that every time the user unlocks the ClientBook, the next time he locks he needs to set a password again?
If that's the case, then I'm thinking if it is possible that we don't remove password on unlock and store the password, so the user only needs to specify a password for the lock command when he/she first adds or changes his/her password. Then subsequently, if he/she locks and unlocks it will just use the same pasword.
edit: after thinking about this more, I realised that its not so easy to store the password securely within the app (I was thinking in UserPrefs? but not sure if it is secure or even possible), and perhaps this one time lock and unlock is enough. What do you think?
4 (commented on others PR)
This method is fine, but are the 2 try-catch blocks are mainly to differentiate between the 2 types of exceptions? I was thinking whether you can condense it into one try-catch block, and in the catch block, you differentiate the 2 cases using the ZipException that was caught.
Actually I was looking at the docs, and found that they didn't really specify what ZipException each method threw, but on their ZipException class, there is a getType() method, which returns a ZipException.Type. (https://javadoc.io/static/net.lingala.zip4j/zip4j/2.7.0/net/lingala/zip4j/exception/ZipException.Type.html)
Perhaps you could check if it is possible to differentiate the cases by checking the exception type? If not then your method is completely fine as it is
5 (commented on others PR)
Just a little bit of unnecessary white space 😃
6 (commented on others PR)
Is there some reason you chose to overload the attemptUnzip() method with this? It seems to me that you could directly call attemptUnzip("") where you want to call this method.
7 (commented on others PR)
I see, that makes sense. Perhaps it could be clearer if you leave a comment or rename the method to indicate that it is for cases where no password was involved?
8 (commented on others PR)
I see, since the API doesn't specify then it's difficult to catch the different cases ourselves. In that case then two try-catch blocks is a nice way to circumvent that👍🏼
9 (commented on others PR)
I agree that the effort to reward ratio is pretty low since it's not a particularly core feature of our application. In that case, let's keep this extension in mind, and if we have time after other core features then we can possibly come back to it in the future.
10 (commented on others PR)
I see, then let's follow the format 😁
11 (commented on others PR)
For the name of this method, I was wondering if the name may be slightly inconsistent with the other get methods of this class, since other get methods in this class returns the object, while this method returns String. A suggestion would be to name it something like nameAndPoliciesToString()
12 (commented on others PR)
There seems to be a lot of white space here. Is there a reason you chose to have a new line after each of the statements?
13 (commented on others PR)
Do you think that naming this method formatOuterBox() is more specific? since there are other VBox instances in other classes or if we extend the UI
14 (commented on others PR)
I see, I think I didn't notice the line breaks were separating each of the variables/objects. now it makes sense!
15 (commented on others PR)
I suggest changing this to ATTRIBUTE, since we used attribute to specify in other parts of the document
16 (commented on others PR)
Similar to the previous comment, I suggest using ATTRIBUTE instead of property
17 (commented on others PR)
This line is a bit confusing, may be instead of "more than 1", it is more suitable to be "at least 1"? Alternatively, we can also say "index must be within the numbers listed on the clientbook"?
18 (commented on others PR)
A little nitpicking, but instead of leaving it as the default case, it might be better to specify each specific case, like
The CURRENT_PASSWORD field can be omitted if ClientBook is not yet locked.
When CURRENT_PASSWORD and NEW_PASSWORD are both specified, ClientBook verifies the current password before locking ClientBook with the new password. >- specifying this case instead of leaving it as default case
When CURRENT_PASSWORD and NEW_PASSWORD fields are both omitted, ClientBook will attempt to lock itself using the last used password that is safely stored on your device.
19 (commented on others PR)
Awesome addition of the column!
20 (commented on others PR)
By the way, I tried to update the data directly from the json file, but not sure if it is because of the zip, but it doesn't work. After I change the json file, I start up the app and it goes back to the previous state. Maybe you guys can test it also, and if it doesn't work, we just remove the "Advanced users are welcome to update data directly by editing that data file." part
21 (commented on own PR)
Made the changes to differentiate command words in this section in the latest commit
22 (commented on own PR)
Added tags back in
23 (commented on own PR)
Added the quick start into the user guide, but release is not yet ready.
24 (commented on own PR)
Great suggestion, done!
25 (commented on own PR)
Great suggestion, made the change.
26 (commented on own PR)
Done!
27 (commented on own PR)
Done!
28 (commented on own PR)
Good point, done!
29 (other comment)
Just did some testing, feature works perfectly! The only small issue is when you input unlock without any parameters, the feedback message to user is
Invalid command format!
lock: Locks ClientBook with a password.
Parameters: CURRENT_PASSWORD(if any) NEW_PASSWORD
Example: lock 12345
And also I think maybe it would make it clearer for the user if we add in the user guide a sentence to specify that when lock is used without parameters, then it will be locked with the current stored password.
After these 2 then its LGTM for me!
@pPris (20 comments)1 (commented on others PR)
I like how you used this plusDays() method in your code, didn't realise it exists
2 (commented on others PR)
Looks well-implemented to me, seems pretty extensible if we need to add more formats or features
3 (commented on others PR)
Perhaps you could consider using different dates here so there's more variety in the tests?
4 (commented on others PR)
Looks pretty thorough to me, nice
5 (commented on others PR)
I'm not sure if this may be necessary, but I think it could be good to have two date strings, parse them, and make sure they're equal in the date value represent? Just to check that the equals method doesn't break
6 (commented on others PR)
A lot of formats seem to be covered here, nice 👍
7 (commented on others PR)
Are there any delimiters your delivery date class is intentionally not meant to handle? If so perhaps you can add an invalid delimiter test here
8 (commented on others PR)
Thanks for the heads up 😃
9 (commented on others PR)
I think it might be better practice to keep request.value() as private and not public? you could have an isEmpty method in request itself
10 (commented on others PR)
It might be better for anyone testing/using the product if you use a variety of requests in this file 😃
11 (commented on others PR)
Think a variety of requests will be good here too
12 (commented on others PR)
Maybe the Name class contains the regex you're looking for? You could adapt the "\p{Alnum}" in the Name regex to \p{Alpha} . I'm basing that off this link (https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html)
Also, I think when the parser part is done, it should be trimming any user input before the Type constructor is called so checking for spaces may not be an issue?
13 (commented on others PR)
Thanks for catching these 💯
14 (commented on others PR)
Think you mean Cost here
15 (commented on others PR)
If these two classes are supposed to be the equivalent of CakeCollate.java and ReadCakeCollate.java, maybe this could be better named after the model name? so something like public class OrderItem(s) implements ReadOnlyOrderItems.
Something trivial, but I think it could make more sense while writing the guides, what do you think?
16 (commented on others PR)
(For your future testing purposes) I wonder if a single " will be accepted? Can be added to tests if you think it's necessary 😃
17 (commented on others PR)
I don't really understand why a delivery date has to be returned in all formats here? 😅 Also, could any of it be abstracted away in your delivery date class?
18 (commented on others PR)
Would using a PREFIX_ALL variable be less bug-prone in case you need to add future tests? Not very sure myself, I think as long as we assert the user doesn't use that prefix, it should be okay?
19 (commented on others PR)
Might want to explain the purpose of this new prefix as a comment, or maybe in the DG. Took me a bit to follow, but seems like a good design choice to have this prefix 👍
20 (commented on others PR)
Seems like this method takes care of the "And" search, I'm not too sure about which part of the code takes care of the "or" search when no prefixes are specified?
21 (commented on own PR)
Got it, changing it to "I can reflect mass cancellations in my database if they occur"
22 (commented on own PR)
Thanks for the comments! Making all the changes you suggested now.
23 (commented on own PR)
Rephrased a few things similar to this suggestion and removed all full stops 😃
24 (commented on own PR)
Good point, added 😃
25 (commented on own PR)
Oops, thank you, fixed
26 (other comment)
LGTM
27 (other comment)
The order prefixes are wrongly written as "/o" instead of "o/"
I think someone can test the example commands given in the UG towards the end of v1.3b to similar errors (perhaps in error messages too)
@QY-H00 (20 comments)1 (commented on others PR)
Here the value of property isn't change to correct format of MB3.5.
2 (commented on others PR)
Here the value of property isn't change to correct format of MB3.5.
3 (commented on others PR)
Here we also need to fix the property to MB3.5 to make it a meaningful test although it's invalid test.
4 (commented on others PR)
I'm not sure if this is inconsistent with Code Quality. Maybe we can check it in the Course Website later.
5 (commented on others PR)
Here the test case need to be implemented.
6 (commented on others PR)
On my own opnion, this should not be commented right?
7 (commented on others PR)
Same for this file.
8 (commented on others PR)
Same problem found^
9 (commented on others PR)
Here the format of deleteTag example seems not correct? Maybe it should be 'deleteTag 1 t/homework'
10 (commented on others PR)
It may be better to add more explaination similar to this?
11 (commented on others PR)
Maybe this kind of command is not added into UserGuide if I'm not wrong?
12 (commented on others PR)
Nice defensive style code
13 (commented on others PR)
Have no idea if the empty else block is acceptable in the CS2103T style. In addition, does that mean we will do nothing when the moduleManager doesn't have the existing module?
14 (commented on others PR)
Similar doubt as above
15 (commented on others PR)
Will it be bettter to implement a method in ModuleManager to check this? Since the implementation here may violate the Law of Demeter.
16 (commented on others PR)
Here existingModuleInStr may be a bit confused since I think it means the list of valid module code right? existingModuleInStr seems a bit closer to the modules of current mapping though it's just personal consideration.
17 (commented on others PR)
Maybe the empty line can be deleted directly? In addition, what if the mapping doesn't contain the module code? If we will never enter the box here we may use an assertion here : )
18 (commented on others PR)
I see. Then maybe we can show a message that json file is manually modified and the corresponding task is not supported?
19 (commented on others PR)
I think if we will never go into the else block then we can modify the if-else structure and use assertTrue(mapping.contains(module.toString())) above. Which seems like this:
assertTrue(mapping.contains(module.toString()));
List<Task> newList = mapping.get(module.toString()); //must ensure Module exists in the listOfValidModules
newList.remove(task);
if (newList.isEmpty()) { //remove the module(key) from mapping if no task is associated with it
mapping.remove(module);
} else {
mapping.put(module.toString(), newList);
}
Do you think it's a good idea?
20 (commented on others PR)
Nice removement for it!
21 (commented on own PR)
sure! I will fix this.
22 (commented on own PR)
OK!
23 (commented on own PR)
Yep. I will delete it.
24 (commented on own PR)
Sure. I will fix it.
25 (commented on own PR)
I think for this one, may be we can discuss in the next meeting.
26 (commented on own PR)
OK!
27 (commented on own PR)
Fixed.
28 (commented on own PR)
This is because default compareTo will make the task with lowest workload shown at the top of list. But I think the feature may be more useful to show the task with highest workload at first. How do you think about it?
29 (commented on own PR)
okay! Do you think this is better?
modulePieChartData.setAll(moduleList.stream().map(module -> new PieChart.Data(module.toString(),
moduleWorkLoadDistribution.get(module))).collect(Collectors.toList()))
30 (commented on own PR)
Resolved.
31 (other comment)
LGTM
32 (other comment)
LGTM
33 (other comment)
LGTM.
34 (other comment)
LGTM
@TeoHoeKeat (19 comments)1 (commented on others PR)
Missing javadocs comment? Missing test?
2 (commented on others PR)
I think the javadocs comment doesn't match the purpose of the constructor. please use the other command available as reference and rewrite the comment.
3 (commented on others PR)
When override, Javadocs will use superclass javadocs when there is no javadocs comment on child. I don't think it necessary to redefine the javadocs comment here.
4 (commented on others PR)
Missing javadocs comment, Missing class test
5 (commented on others PR)
Update the test case on DictionoteParserTest? I notice there no test added, please add all the required test for all the method you added, if applicable.
6 (commented on others PR)
Update ParserUtilTest?
7 (commented on others PR)
May I ask why does the addressbook store note list? I remember there is a ReadOnlyNote class.
8 (commented on others PR)
Missing javadocs comment
9 (commented on others PR)
Update the javadocs comment?
10 (commented on others PR)
using wrong placeholder
11 (commented on others PR)
FXML not defined in MainWindow.FXML. please use noteListPlaceholder instead
12 (commented on others PR)
The stud is used for AddCommand, It is unnecessary to add note method here. In addition, AddNoteCommand test should be done in a separate class.
13 (commented on others PR)
mayble we should be consistent here, and use week/ header/ maincontent/, or w/ h/ mc/
14 (commented on others PR)
addnote [c/CONTENT] [t/TAG]... instead of [c/CONTENT]... [t/Tag].. as '...' indicate mulitple
15 (commented on others PR)
maybe mention what the note is sort by? e.g alphabetically
16 (commented on others PR)
the UI here refers to the panel, not the model definition. When using ListDefinition, you use UiActionOption.DICTIONARY_LIST, this will open the list panel to show the definition
The UIActionOption refer to the Panel, not the model. hence DICTIONARY_DEFINITION do not exist as no such panel exist.
p.s. please remove DICTIONARY_DEFINITION and use DICTIONARY_LIST
17 (commented on others PR)
DeleteNote?
18 (commented on others PR)
I suggest doing this in a separate class. Model should not be responsible to be writing to file.
19 (commented on others PR)
resolve conflict?
20 (commented on own PR)
I have asked the question via the forum, the lecturer said no need to follow java coding standard for fxml file generated via scene builder
21 (commented on own PR)
I have asked the question via the forum, the lecturer said no need to follow java coding standard for fxml file generated via scene builder
22 (commented on own PR)
yap
@lyueyang (19 comments)1 (commented on others PR)
Should there be a space after female? Not an issue, just a formatting thing really
2 (commented on others PR)
Just like the one above, the index numbers in the example are missing the c/ prefix
3 (commented on others PR)
The index in the example lacks the c/ prefix
4 (commented on others PR)
Should the javadocs be represented like this or would a single line as per the original document be better?
5 (commented on others PR)
same goes for here as per above
6 (commented on others PR)
closing as upon discussion, we agreed that it's alright as checkstyle tests have passed it
7 (commented on others PR)
closing as upon discussion, we agreed that it's alright as checkstyle tests have passed it
8 (commented on others PR)
wrong spelling for passenger
9 (commented on others PR)
Address app should be changed back to GreenMileageEfforts
10 (commented on others PR)
closing, resolved on improved code quality
11 (commented on others PR)
Could you maybe change this to find a/serangoon returns Bernice Yu, David Li instead? thanks!
12 (commented on others PR)
adjusted the description, closing comment
13 (commented on others PR)
is this necessary? thinking because you could just use TripTime's internal toString() method implicitly but it could also be that im not too familiar with this
14 (commented on others PR)
maybe keeping the requireNonNull might be useful since that's what we're encouraged to do this week
15 (commented on others PR)
could we actually just change this to isSameTrip to keep the code shorter?
16 (commented on others PR)
'diver' mentioned here instead of driver, no big issue just to take note for next implementer
17 (commented on others PR)
Should this be DeleteCommand instead of PoolCommand?
18 (commented on others PR)
sorry, why's it no longer a requirement to check for tripTime?
19 (commented on others PR)
right, that makes sense, thanks!
20 (commented on own PR)
Good catch, let me amend that
21 (commented on own PR)
have clarified with mark, such an implementation raises issues within the compiler as PREFIX_NAME.toString() will not be considered as a constant
22 (commented on own PR)
Have moved this to ParserUtil as discussed
23 (commented on own PR)
Resolved this by changing logic in implementation as discussed
24 (commented on own PR)
Rectified this, thanks for pointing it out!
25 (other comment)
LGTM
thank you 😃
26 (other comment)
As we are no longer implementing this, can we close this issue?
27 (other comment)
In a previous PR this was address but have yet to manually test that this works with live profiles as well.
28 (other comment)
Will close this issue when I'm able to manually test again live profiles with price
29 (other comment)
Have addressed this in attached PR. File name has been changed to GMEdata.json
@clarlzx (16 comments)1 (commented on others PR)
Perhaps this line can be broken down into smaller parts for better code readability?
2 (commented on others PR)
Perhaps this line can be broken into smaller parts for better code readability?
3 (commented on others PR)
Maybe this is not needed and can be removed?
4 (commented on others PR)
Perhaps this can be broken into points for easy reading.
i.e. Reason for current choice:
...
...
5 (commented on others PR)
For the steps in the scenario, perhaps we can standardise to "Step 1", etc. Like edeline's and the undo portion which existed in AB3 before hand.
6 (commented on others PR)
Thanks for correcting this, totally forgot about this 👍
7 (commented on others PR)
Would be good if you could separate the export and import into 2 different parts.
8 (commented on others PR)
Perhaps you could separate the guide for exporting and importing data?
9 (commented on others PR)
Looks good 👍
10 (commented on others PR)
Looks good 👍
11 (commented on others PR)
Is "all clears all" a typo?
12 (commented on others PR)
Maybe don't need to edit checkstyle.xml here as the previous indentations look correct?
13 (commented on others PR)
Same comment as for checkstyle.xml changes.
14 (commented on others PR)
Can remove this part if not needed.
15 (commented on others PR)
We should make sure that parts of code that require option use this class for code standardisation.
16 (commented on others PR)
Maybe change name to tags instead, since it is a list?
@VRSoorya (15 comments)1 (commented on others PR)
Remember to clean up the comments to match Residence instead of Person
2 (commented on others PR)
Address Book comments need to be changed to Residence Tracker too
3 (commented on others PR)
Class name has to be UniqueBookingList I believe?
4 (commented on others PR)
I think you meant .isSameResidence here?
5 (commented on others PR)
do you mean seedu.address.model.booking.Booking? I think you might have forgotten to refactor the person package to 'booking' instead?
Once you refactor, you probably don't need this import statement since the Booking is also in the same package and you can use it directly in this file
6 (commented on others PR)
Hey use logging instead! I need to add more logs myself.
7 (commented on others PR)
Can we refactor this class to be named as VisitorName? similar to how we did for Residence by calling it ResidenceName?
8 (commented on others PR)
And we could call this class just Name?
9 (commented on others PR)
I think we can allow any special characters for ResidenceName because why restrict the user unnecessarily right?
So a validity check could be to allow any non-empty strings and no " "?
10 (commented on others PR)
Hey, I think you could use these Prefixes directly by importing them without the need for these getters! Since they're public static similar to how we see it used it other command classes 😃
11 (commented on others PR)
Nice thanks for adding the new commands in too!
12 (commented on others PR)
I'm thinking maybe instead of showing c/[y or n] we can write c/VALID_CLEAN_STATUS and then mention that VALID_CLEAN_STATUS for clean: 'y' or 'clean' and unclean: 'n' or 'unclean'?
13 (commented on others PR)
I think we need these to make bookings to be used in tests later but maybe could rename to PHONE_DESC_BOOKING1 and PHONE_DESC_BOOKING2?
14 (commented on others PR)
I left this commented out to be built on later when we add more tests so could we keep sorry!
15 (commented on others PR)
probably need to keep this line too to make bookings in tests later?
16 (other comment)
Yup such differentiation is possible and reasonable to accommodate residence names like Pinnacle@Duxton while having regular names for visitors
17 (other comment)
Regarding the tests maybe we could keep them commented and re-evaluate in v1.4?
@stein414 (15 comments)1 (commented on others PR)
This seems different from the ab3 alternative format provided. Maybe using the provided format would be better? Do let me know if I am mistaken.
The referenced link is here: https://se-education.org/addressbook-level3/DeveloperGuide.html#design-consideration
2 (commented on others PR)
Perhaps the details not choosing the alternative could be added to be clearer why it was not used in the end
3 (commented on others PR)
This is a small one but maybe add a space between valid and '''
4 (commented on others PR)
Maybe reword the second sentence as it feels a little weird to read.
5 (commented on others PR)
Perhaps abstract the 3 into a variable to avoid magic numbers
6 (commented on others PR)
The tests cases seems extensive. Good work
7 (commented on others PR)
Maybe a enum like "CommandType" would make more sense as it is somewhat overcrowding the constructor. The check could be against the enum value instead if needed
8 (commented on others PR)
The naming seems ambiguous
9 (commented on others PR)
This javadocs probably should be residents instead of persons
10 (commented on others PR)
Person -> Resident
11 (commented on others PR)
Perhaps use DuplicateResidentRoomException instead
12 (commented on others PR)
Perhaps change the resident references in this file to resident rooms (both in comment and code)
13 (commented on others PR)
resident -> resident room
14 (commented on others PR)
Resident -> ResidentRoom
15 (commented on others PR)
Resident -> ResidentRoom
16 (other comment)
The inconsistency is due to the need to distinguish room.RoomNumber from issue.RoomNumber
17 (other comment)
I would like to discuss if the command history should also include failed commands. I think there is merit to mimic the same behaviour where the invalid command can be access via up and down arrow keys so that a Power User can edit the invalid command rather than retype it all.
If we do go down this path, I think a possible implementation is that each history entry will keep a field to keep the corresponding command used. Thus, if the field is null, it indicates an invalid command, otherwise it indicates a valid command.
18 (other comment)
I would like to discuss if the command history should also include failed commands. I think there is merit to mimic the same behaviour where the invalid command can be access via up and down arrow keys so that a Power User can edit the invalid command rather than retype it all.
If we do go down this path, I think a possible implementation is that each history entry will keep a field to keep the corresponding command used. Thus, if the field is null, it indicates an invalid command, otherwise it indicates a valid command.
Hmm, thanks for the suggestion. SunRez currently does not consume the user's input when a command is invalid, so a power user can already edit an invalid command easily.
I see, that makes sense. In that case, the suggested feature seems to be not needed.
19 (other comment)
Reopening as issue commands are not covered yet.
@litone01 (14 comments)1 (commented on others PR)
Priority and phone has the same prefix, may need to be careful later
2 (commented on others PR)
I suppose this file is not updated fully yet
3 (commented on others PR)
are we gonna change the prefix_phone and email all that?
4 (commented on others PR)
oh ok haha
5 (commented on others PR)
this should not be imported yet.
6 (commented on others PR)
this should not be imported yet.
7 (commented on others PR)
are we gonna change the prefix_name and phone and email etc
8 (commented on others PR)
this may not be an issue but I am thinking maybe we will need something similar for our tests later
9 (commented on others PR)
ah jiahe I also made this changes, we may have conflicts later
10 (commented on others PR)
ah jiahe I also made this changes, we may have conflicts later
11 (commented on others PR)
can we rephrase the message to "Please ensure the deadline provided is not earlier than today. This means only today and date later than today are allowed." or something similar haha @SoulUseless a better suggestion? same for the error message for event because the original message sounds a bit wrong hmmm
12 (commented on others PR)
wait ah I think we are trying to allow today to be added? like today is 2021-03-29, it should be allowed as a deadline?
13 (commented on others PR)
happen before today?
14 (commented on others PR)
can try to abstract out some processes? This looks like a deep nested or too long method:(
15 (commented on own PR)
needs because it fails some test case, I suspect storage is not working properly or something
16 (commented on own PR)
this format follows java syntax, I cant recall the difference hmmm
17 (commented on own PR)
oh if you are removing it I can add it back
18 (other comment)
Looks great thanks for the update!
19 (other comment)
@ljhgab i think this may have been done?
20 (other comment)
@ljhgab I think this may have been done?
21 (other comment)
This is an invalid input, do you mean an error message should be shown?
22 (other comment)
temporarily on hold
23 (other comment)
need to write as close #200 close #201 haha otherwise it only closes 200
24 (other comment)
pending
@riyadh-h (14 comments)1 (commented on others PR)
Shouldn't these import statements be explicit in order to comply with the Java coding standard?
2 (commented on others PR)
Shouldn't the length of any line of code be limited to 120 characters maximum?
3 (commented on others PR)
Does the maximized="true" part starts the program in maximized window mode by default?
4 (commented on others PR)
Should the code block in lines 18-20 be written inside the constructor in line 22?
5 (commented on others PR)
Should both paths use the same "\nLocal data file location : " string prefix?
6 (commented on others PR)
Should this semicolon be here?
7 (commented on others PR)
Shouldn't the JavaDoc for this method contain a tag for the parameter note? (i.e., @param note >description>)
8 (commented on others PR)
Oh I see, sorry for the misunderstanding.
9 (commented on others PR)
Shouldn't it be from the notes list instead?
This issue appears in other parts of the code as well
10 (commented on others PR)
Shouldn't it be new DeleteNoteCommand object instead?
This issue appears in other parts of the code as well
11 (commented on others PR)
Shouldn't it be from the list instead?
12 (commented on others PR)
Shouldn't it be show no note instead?
13 (commented on others PR)
A minor issue, but shouldn't there be a space before and after and note book and and dictionary content?
14 (commented on others PR)
Shouldn't this be listnote instead of editnote?
15 (other comment)
I notice some class may need to be renamed:
- PersonUtil -> ContactUtil?
- PersonListPanel -> ContactListPanel?
- PersonCard -> ContactCard?
- JsonAdaptedPerson -> JsonAdaptedContact?
otherwise, LGTM
Right, but those were left unchanged because other Contact commands rely on them.
I will rename them when I update the other Contact commands 👍 .
@chewwh09 (14 comments)1 (commented on others PR)
Just a suggestion. Would it be better if you put everything in a try-catch block?
try {
if (test.matches(VALIDATION_REGEX)) {
LocalDate.parse(test);
return true;
}
} catch (DateTimeParseException | NullPointerException ex) {
return false;
}
2 (commented on others PR)
Personally, I think this is okay since this is within the test folder and we are abstracting the value through key-value mapping. Furthermore, we do not many variables so as long as each JSON object follows the same sequence I am good.
3 (commented on others PR)
Why did you remove this check?
4 (commented on others PR)
I think if you can avoid nesting if-else it would be great. So you can do
(test.matches(VALIDATION_REGEX) && value > 0) {
return true;
}
It increases readability as well.
5 (commented on others PR)
But as long as your Long.parseLong(test) is the second condition to test.matches(VALIDATION_REGEX), it will be fine due to short-circuit.
6 (commented on others PR)
I assume you use this line of code to debug and forgot to delete it.
7 (commented on others PR)
I get what you are trying to do here. But your code here seems like you are comparing two items instead of comparing the item's quantity.
For me personally, I feel like this entire code should be abstracted to the item class and name it as quantityPriorityComparison.
What do others think?
8 (commented on others PR)
Details are in quantityComparator and item class
Same as the quantityComparator, I think this method body should be abstracted to the item class.
What do others think?
9 (commented on others PR)
Carry on from quantityComparator and ExpiryDateComparator
All this method can be removed and replace with a method like quantityPriorityComparison and expiryDateComparison. It would somewhat be like a compareTo method in the Comparable interface.
10 (commented on others PR)
You forget to add the throws exception in the javadocs
11 (commented on others PR)
Agree with kums!
12 (commented on others PR)
Prevent using magic boolean. Other than that LGTM
13 (commented on others PR)
Just a suggestion. Would it be better if you abstract the inner if-else clause into another function? Because both the if-else clause looks similar. Maybe, you can have the function takes in another argument to differentiate these 2 different if-else clause?
14 (commented on others PR)
Just wondering, does removing this test decrease the test coverage? Would it be better if you change it to assertParseSuccess since we are allowing negative numbers now.
15 (commented on own PR)
All right noted!
16 (commented on own PR)
Yes, it will work as normal. I am using inheritance to achieve both showing all items when no argument is given and also showing filtered items when arguments are given.
17 (commented on own PR)
I think it is fine. I follow the AB3 format, but we can always revisit the User guide and developer guide along the way. 😄
18 (commented on own PR)
Great catch! Thanks! I will change according!
19 (commented on own PR)
I agree that the message is the same as the above two lines. But, the description doesn't fit my usage, that's why I added a new string. I shall change to a different string description.
20 (commented on own PR)
All right noted! Will change accordingly.
21 (commented on own PR)
In my ItemExpiringPredicate Class i use a method called days.between to check for the difference in dates and it returns me a type long.
There are actually no ways of going about this. It's either I parse int to long in this class (which I did) or I parse long to int in my ItemExpiringPredicate Class. Since this class name is called ReminderCommandParser, I feel all the parsing should be done here hence I chose the first method.
22 (commented on own PR)
@Md-Fazil All right I will try to do so.
@JayChenYJ I personally feel it's not good to allow the user to input "reminder 6 hahahaha" as an acceptable input.
23 (commented on own PR)
We have to split the string because the parameter can go can be 1 or multiple digits so I just do substring, I have to abstract out the number. With input as "reminder 3 hahahaha", I still have to abstract out the 3 using split.
24 (commented on own PR)
I feel like prefixes should solely be used to detect each attribute of the items. Whereas this is more of detecting a keyword.
25 (commented on own PR)
All right! I will make it case-insensitive.
26 (commented on own PR)
All right! Will change accordingly.
27 (commented on own PR)
All right will change according!
28 (commented on own PR)
So I should break into 2 statements?
ExpiryDate expiryDate = item.getExpiryDate();
LocalDate itemExpiryDate = expiryDate.expiryDate;
29 (commented on own PR)
This wouldn't be the case. It will still work regardless of how many spaces are in between the reminder and the number.
Eg. "Reminder 3" would work the same as "Reminder 3"
30 (commented on own PR)
Basically, I abstract the user input string into arrays of string. The stringArgsArr[0] has to be a number in a string format and the stringArgsArr[1] has to be a "days" or "weeks". With these 2 valid arguments, I will proceed to parse the number of days in total. If no days or weeks are declared in the user input, by default the number given is in timeUnit days.
31 (commented on own PR)
All right because initially, the plan we discussed was to make the input more lenient to allow the user to input "reminder 3 days" or "reminder 2 weeks". But I can make it work using prefixes as well, but I probably going to do it on another branch "Modify Reminder Feature" for v1.3
32 (commented on own PR)
All right!
33 (commented on own PR)
I made changes to the assertion. It's no longer in this class hence the if clause is still valid.
34 (commented on own PR)
I added the test back.
35 (commented on own PR)
All right thanks!
36 (commented on own PR)
All right thanks!
37 (commented on own PR)
All right thanks!
38 (commented on own PR)
I am just following the format of other use cases.
39 (commented on own PR)
All right will do after i merge the master to this branch! 😄
40 (commented on own PR)
This itself is a variable already. Does it still count as a magic number though? Because from my understanding, magic numbers are when it appears in the method and reader has no understanding of what the magic number represents.
41 (commented on own PR)
All right!
42 (commented on own PR)
All right noted.
43 (commented on own PR)
All right noted!
44 (commented on own PR)
Yes they do!
45 (commented on own PR)
But it was stated that "given today is 30 March".
Solved through other platform.
@oeiyiping (13 comments)1 (commented on others PR)
Correct me if I'm wrong - DisplayFilterPredicate.test() will return true if field is specified, and only these specified fields will be set as visible and managed. If that is the case, can I clarify what you meant by "returns true (...) should be hidden"?
2 (commented on others PR)
Looks good to me 👍
3 (commented on others PR)
Just spotted this: "@param displayFilterPredicate that returns true if prefix linked control should be hidden",
looks to be the same mistake as before (ie. returns true if (...) should be shown). Maybe check the other areas where this line was copy-pasted, to see if there are other uncaught ones.
4 (commented on others PR)
Just spotted this: "@param displayFilterPredicate that returns true if prefix linked control should be hidden",
looks to be the same mistake as before (ie. returns true if (...) should be shown).
5 (commented on others PR)
Correct me if I'm wrong - this Command class is different from the one in address/logic/commands right? There is one Command class in that path, so I'm not sure if having two classes of the same name would be confusing.
6 (commented on others PR)
Good point, thanks for the explanation. No problem here then.
7 (commented on others PR)
Maybe rename the boolean variables to eg. isX, so that the variable name immediately implies a boolean value. In general it is clear that these are boolean values, but perhaps a rename would be safer to comply with the textbook recommendation.
8 (commented on others PR)
Your suggestion sounds good to me!
I am aware that some of the pre-existing boolean variables from AB3 might not seem to exactly comply with the textbook recommendation, and have thought about just leaving the variable names as is. However, I currently feel that it is better to err on the safe side, as it is always possible for the reviewer to argue that "just because it was originally named this way, doesn't mean it is correct". What is your opinion on this matter?
9 (commented on others PR)
Nice, LGTM now! Will be marking this conversation as resolved.
10 (commented on others PR)
Maybe it would be easier for the reader to understand what this line means, by providing an example of how the index of the focused contact can be autofilled. At the moment, it might be difficult to visualize how this feature works (referring to the point on autofilling index).
11 (commented on others PR)
Slight typo for component
12 (commented on others PR)
Maybe capitalize Tab for consistency with the other two keys?
13 (commented on others PR)
Perhaps rename this to better imply that this is a boolean.
14 (commented on own PR)
Good catch, will be merging after fixing the typo.
15 (commented on own PR)
Oops, forgotten to include it in my PR description. I provided the reasoning in the relevant commit message, so I'm going to paste it here:
This change fixes bug where parser previously cannot distinguish
between eg. -p and -pp. Now, the parser can differentiate between
-p and -pp , as -p is not a front substring of -pp due to
the whitespace char at the end of -p .
Accordingly, AddressBookParser has been modified such that it only
removes leading whitespaces, and no longer removes trailing
whitespaces. This is to account for optional options such as -r ,
where -r will not be registered as a valid key since the
whitespace char is trimmed away before the parsing of keys.
Not removing trailing whitespaces should not affect the eventual
values of the keys, as tokenizer will still trim the parsed value
before returning it. ie -a test street still results in
the address value being test street, without trailing spaces.
16 (other comment)
LGTM
17 (other comment)
LGTM!
18 (other comment)
I realised that the help text for
addcommand does not include spaces between the flag and the value. I'm guessing theeditcommand will have this issue too
Thanks for catching this. I'll fix it up in my next PR, after checking the other commands that might be affected.
19 (other comment)
@oeiyiping will you be updating the diagrams for your changes to Remarks?
Was intending to settle diagrams in 1.4. Unless we are aiming to complete diagrams in this milestone?
20 (other comment)
After testing the new prefix parsing implemented in this PR, I think there are fundamentally a few problems here, especially with the filter and alias command.
- The filter command is having trouble working as intended. For example, if I want to filter by address, I would need to input
filter -awith whitespace behind.
- Similar, typing
filtershould clear all existing filters. However, without trimming the trailing whitespaces, the filter command will recognise the command slightly different and instead filter the list of persons to show just the name.
- Alias commands are also having problems when parsing and checking the validity of the commands to be aliased.
Thanks for pointing the errors out, I should not have assumed that these cases are already accounted for in the current testcases. I will see how else I can fix this bug while preserving the Bash-like format. Changing this PR to draft until then.
@maxxng (13 comments)1 (commented on others PR)
Did you mean to edit all the portfolios?
2 (commented on others PR)
Did you mean to edit this as well?
3 (commented on others PR)
Not all commands will be inside. Unless we want to change the implementation
4 (commented on others PR)
Refer to line 262
5 (commented on others PR)
Can consider refactor through law of demeter?
6 (commented on others PR)
Should we delete this instead?
7 (commented on others PR)
Should we delete this instead?
8 (commented on others PR)
I have edited the help command already in the new PR.
9 (commented on others PR)
All of the message constrains for commands have a certain format that we use, is that format applicable here?
10 (commented on others PR)
Is this test case correct?
11 (commented on others PR)
Did you mean for this month to be valid but the frequency to be invalid?
12 (commented on others PR)
Should the startTime be made 12:30? Or can it be empty?
13 (commented on others PR)
Is the javadocs okay in this format?
@JulietTeoh (13 comments)1 (commented on others PR)
Because each section of our project has an in-charge (e.g Yongliang is currently in charge of the developer guide), I think we should assign the in-charge guy of that section to review the pull request. It can allow the reviewing of pull reviews to be more spread out among everyone, as opposed to one person doing a majority of the reviewing.
2 (commented on others PR)
Maybe you should consider having 2 overloaded methods:
public boolean equals(Object other) and public boolean equals(SendCommand other)
but it's ok if u prefer yr current way.
3 (commented on others PR)
Will be good to follow the spacing format shown in other MESSAGE_USAGE classes for more readability.
4 (commented on others PR)
I think this extra indentation is not necessary?
5 (commented on others PR)
The spacing for here too
6 (commented on others PR)
I think we should discuss more if we should allow duplicate endpoints because other TA/tester may view it as a bug.
7 (commented on others PR)
Same duplication comment as above
8 (commented on others PR)
Same duplication comment as above
9 (commented on others PR)
It will be good to include a check that method can only be "POST" or "GET" or "PUT" or "PATCH" or "DELETE", just like how the email checked that it had an email had @ and .com
10 (commented on others PR)
Else, the method will throw an error
11 (commented on others PR)
Would these test cases not being changed cause the tests to break down?
12 (commented on others PR)
oh sorry :>
13 (commented on others PR)
Just to confirm, Header's regex checks that a header is in the JSON format right?
If not, such deletion before checking may lead to bugs.
14 (commented on own PR)
@ong6
if a user wants to remove a tag/data, they will most likely type
"edit 1 -t" and then its isn't removing the tag/data if the prefix is "-t "
which makes them think it is a bug / something is wrong (i was stuck on this for quite long)
15 (commented on own PR)
I checked ab3 there are no space in their prefix so i think just follow that bah
16 (commented on own PR)
I will resolve in another pr :>
17 (commented on own PR)
O man
18 (commented on own PR)
done brudda
19 (commented on own PR)
done too
20 (commented on own PR)
done
21 (other comment)
wrongly tried to merge master instead of the respective branches
22 (other comment)
refactor name to method (-x)
refactor address to url (-u)
23 (other comment)
I will update the docs for my 2 pull requests in another issue tracker
24 (other comment)
I did a quick skim of the files and it seems that the whitespace removed from the likes of
PREFIX_METHODare instead being introduced in the strings they are being concatenated with. Am I overlooking anything?
Hi the only thing in the PR that affects code is the prefixs being changed in CliSyntax.java. For the add, edit and run, I just made the error command messages more readable, for example: from
"add -xget -usomeurl -hsomeheader" to
"add -x get -u someurl -h someheader"
25 (other comment)
Okie @ong6 introduced the whitespace in
PREFIX_METHODin this commit 5 days ago so I think's best for him to do the review.
@ong6 so heres a more in depth view of whats wrong with PREFIX_METHOD = "-x "
using an example of "edit 1 -x "
when passed into the parseIndex method of ParserUtil.java, it calls
string trimmedIndex = oneBasedIndex.trim(); which trims the string to "edit 1 -x".
then because PREFIX_METHOD is "-x " (with the space), StringUtil.isNonZeroUnsignedInteger(trimmedIndex) will be true, because trimmedIndex will be equal to "1 -x", which leads an exception of the EditCommand.MESSAGE_INVALID_INDEX being thrown, instead of a more specific error message from the parseMethod method.
Also, if PREFIX_METHOD = "-x ", doing "edit 1 -t " or "edit 1 -h " does not work to remove tags/header because of the same reasons as stated above.
TLDR: there should be no space in all prefixs, unless you want to change a ton of other codde
26 (other comment)
@tjtanjin the run and send test lowly unreliable they sometimes pass sometimes fail on my comp and I couldn't even commit my work on sourcetree.
27 (other comment)
For me, the mainwindow background disappears after I toggle
28 (other comment)
oh ooopsie
29 (other comment)
Uhm, I just tested it. But it seems that the
clearcommand does not show this picture? Is it only meant to be used forlistwhen there are no endpoints?
yes i only show the pic if the user types list when the endpoint list is empty
30 (other comment)
done
@nickyfoo (12 comments)1 (commented on others PR)
if (lst.isEmpty() || isDifferentFromLatest(s)) {
2 (commented on others PR)
private boolean isDifferentFromLatest(String s) {
3 (commented on others PR)
This doesn't seem like a very robust check, since it would allow dates such as 2020-99-99, which would be an invalid birthday as well.
I think we could instead use the Java LocalDate class, which provides the parsing methods as well.
You could refer to what I did in my IP, for the deadlines. https://github.com/nickyfoo/ip/blob/master/src/main/java/duke/command/DeadlineCommand.java
or here for usage of LocalDate class
4 (commented on others PR)
It might be best not to catch all exceptions here, perhaps writing the specific ones which might be thrown by the Birthday constructor?
5 (commented on others PR)
| `**` | Night owl | Enable dark mode | Use the app safely in dark environments |
6 (commented on others PR)
Reminder to change this to not show an X as it's kind of unsightly
7 (commented on others PR)
No, we decided that the cross for an undone Event would look very unappealing, and so we've removed it
8 (commented on others PR)
It seems like the method is doing more than it should, in the sense that it is checking if the person has tags, and adding it to editedPersons, which might violate some abstraction principles.
On that note, the method name is misleading, since it implies that it only checks if there are tags.
I would suggest to change this method signature to private boolean hasTags(Person personToCheck), which will return true if the person has the tags, otherwise false, and leave adding the person to editedPersons to the execute method
9 (commented on others PR)
* The birthday must be in a valid date format, with or without year, and must be in the past if the year is specified, e.g. 13 Jan, 13 Mar 1997
10 (commented on others PR)
Can be invoked repeatedly until there is no more history from the current session.
11 (commented on others PR)
* The date must be in a valid date format with year, e.g. 2022-05-07, 2 feb 2021
12 (commented on others PR)
Method name is a little misleading, as it seems to imply a check (i.e. returns a boolean). I think this method shouldn't be calling deletedPersons.add(person), as it might violate some abstraction principles.
It might be good to abstract this out into a boolean hasTags() method, that checks these things, and then leaving the adding to deletedPersons to execute.
13 (commented on own PR)
Thanks, corrected.
14 (commented on own PR)
Added, thanks
15 (commented on own PR)
Incorporated into latest commit, thanks!
16 (other comment)
LGTM
17 (other comment)
LGTM
18 (other comment)
LGTM
19 (other comment)
INFO: Added state to stateHistory. Current number of states is: 2. Currently on state: 1is the logged message. Seems like we can have a feature to easilyredoas well.
Yup, definitely planning to in a future iteration. I mentioned it in a currently unimplemented nextState method in StateHistory
20 (other comment)
Ah that's true, will do that instead.
21 (other comment)
Yup, I think it'll be good to have the help command provide both immediate (summarised) help, and a reference to the link at the bottom for users to explore the nuances
22 (other comment)
Apologies, it slipped my mind that Birthdays should be sorted by Month and Day instead of including year
23 (other comment)
The same exception is thrown when tags -f [CHAR] is called, where CHAR is any character not in any tags, e.g.
tags -f z for the sample data.
24 (other comment)
Fixed by PR #161
25 (other comment)
As discussed before, since the StateHistory is refreshed on each running of the application and does not carry over between sessions, it is unlikely that it will cause a memory problem, and so it will not be implemented for this milestone.
26 (other comment)
Should the
KeyCombinationevent handling fall under the samehandleUserKeymethod? They seem to conceptually belong together.
Added to the latest commit!
27 (other comment)
A more recent PR in #209
@zhengruoxin (12 comments)1 (commented on others PR)
* At the most recent input, pressing `Down` arrow key once more clears the text box.
2 (commented on others PR)
* Pressing `Up` arrow key in the text input panel reverts to earlier input.
3 (commented on others PR)
+ PREFIX_BIRTHDAY + " 1999-06-01 "
4 (commented on others PR)
Will writing "You can write anything in remarks, " be more easily understood?
5 (commented on others PR)
This might sound a little bit ambiguous, as the user may confuse it as the person he wants to edit does not have an empty remark. Maybe can change it to something like “You have already typed something!” ?
6 (commented on others PR)
stringSort += "Sorted names ";
7 (commented on others PR)
stringSort += "Sorted birthdays ";
and in "chronological order" instead of "ascending" maybe?
8 (commented on others PR)
stringSort += "Sorted by upcoming birthdays. ";
9 (commented on others PR)
model.getFilteredEventList().size()) + " No events met the requirements.");
10 (commented on others PR)
Name sounds like a person imo, maybe "titles" to differentiate? like birthday & date, remark & details
11 (commented on others PR)
requires/ required? require might sound like asking the user to do something
12 (commented on others PR)
+ "\nNobody met the requirements.");
13 (commented on own PR)
That's true. I considered LocalDate but wanted to keep to standardising using isValidBirthday boolean to check for validity. Will try to see if I can use both, else will switch to LocalDate. Thanks!
14 (commented on own PR)
Used LocalDate to check for validity in latest commit.
15 (commented on own PR)
Separately caught IllegalArgumentException (for invalid year) and DateTimeException (for invalid format) in latest commit.
16 (commented on own PR)
Adopted in latest commit.
17 (commented on own PR)
Will leave it to after append is implemented to see how they fit.
18 (commented on own PR)
This method is following the displayPersons() method in all the delete commands to standardise. Should we change it for all occurrences?
19 (commented on own PR)
Adopted in latest commit.
20 (commented on own PR)
Adopted in latest commit.
21 (commented on own PR)
Adopted in latest commit.
22 (commented on own PR)
Adopted in latest commit.
23 (commented on own PR)
Adopted in latest commit.
24 (commented on own PR)
Adopted in latest commit
25 (commented on own PR)
Good catch! Have edited the implementation in latest commit, changed the method name to hasTags that returns a boolean and leaves the addition to execute.
26 (other comment)
LGTM
27 (other comment)
LGTM
28 (other comment)
LGTM
29 (other comment)
LGTM
30 (other comment)
LGTM
31 (other comment)
The year can be useful to remember a friend's age though, so you won't eg. accidentally wish your friend. "Happy 21st" when it's their 22nd.
32 (other comment)
Some ideas (screenshots from online):
33 (other comment)
I think it can be done for the filtered list, so the user can subset the group he wants to delete the tag from.
34 (other comment)
Maybe make the new theme a separate file and keep darktheme (for a possible future enhancement to let user switch between themes
Oyea good idea! Have adopted in latest commit
35 (other comment)
When the user input invalid parameters after a flag, the result is the same as elist and also displays a "Listed all events" success message. Optional though can consider to display another message to remind them about the missing field (can be error or just a message).
eg. elist --any sdjsjhf, or elist --exact xcvxg
(Actually this behaviour is also in list for persons haha can leave it or do "for fun" next time if want)
36 (other comment)
delete without parameters is the intended replacement for clear and edelete works to clear events list.
((sorry i forgot!!)
@SoulUseless (12 comments)1 (commented on others PR)
Are you missing the "task" in your example?
2 (commented on others PR)
Is it possible to add a constructor with some parameters instead of just an empty class?
3 (commented on others PR)
Is it possible to add a constructor with some parameters instead of just an empty class?
4 (commented on others PR)
Is it possible to add a constructor with some parameters instead of just an empty class?
5 (commented on others PR)
Is it possible to add a constructor with some parameters instead of just an empty class?
6 (commented on others PR)
Instead of having separate class files for startDate and endDate, it might be better to condense into a single Date class. Same for the startTime and endTime
7 (commented on others PR)
Is it possible to add a constructor with some parameters instead of just an empty class?
8 (commented on others PR)
Is it possible to add a constructor with some parameters instead of just an empty class?
9 (commented on others PR)
Is it possible to add a constructor with some parameters instead of just an empty class?
10 (commented on others PR)
Javadocs not updates here.
11 (commented on others PR)
DateTimeFormatter and Regex validation format should follow that of the UG: YYYY-MM-DD
12 (commented on others PR)
I think you mean ".json" here.
13 (commented on own PR)
right, missed it. will work on this now.
14 (commented on own PR)
right, but i think instead of storing a null value ill set it to a default priority value
15 (other comment)
I am not sure whether Deadline should extends Task. Except from that, LGTM.
Might be better to have a single Date class under models/commons instead since the functionality will be around the same since they are all dates.
16 (other comment)
Adding of constructors to underlying attribute classes delayed.
17 (other comment)
Added DG updates to the PR:
Created skeleton DG for future edits
Updated AB3 Storage documentation to Sochedule Storage documentation (closes #158)
Added Implementation details of sortTask into DG
@arihantjain97 (12 comments)1 (commented on others PR)
Great job, Good formatting
2 (commented on others PR)
Good value proposition
3 (commented on others PR)
great job!
4 (commented on others PR)
great job
5 (commented on others PR)
Great job, follows SLAP everywhere!
6 (commented on others PR)
Good, follows SLAP
7 (commented on others PR)
Great Job, SLAP used
8 (commented on others PR)
SLAP-tastic!
9 (commented on others PR)
Great job
10 (commented on others PR)
Good job
11 (commented on others PR)
Good Job
12 (commented on others PR)
Great documentation
13 (other comment)
Merging to main, DG should update for everyone
14 (other comment)
ignore this
15 (other comment)
implemented help command
16 (other comment)
implemented delete command
17 (other comment)
implemented edit command
@figo2127 (12 comments)1 (commented on others PR)
Maybe assign Set>Tag> tags = firstTask.getTags(), to make code more readable. But not a big issue.
2 (commented on others PR)
LGTM!
3 (commented on others PR)
It might be more "visual" to write this in a few more lines. But no big deal lgtm.
4 (commented on others PR)
Perhaps it'd be better to use variables and methods to decide the size of String[] expectedTags, since "multiple" doesn't always mean 2.
5 (commented on others PR)
Looking neat!
6 (commented on others PR)
nice defensive programming
7 (commented on others PR)
maybe medium and high's first letter should be capitalized like Low?
8 (commented on others PR)
cool! Wld be good too if u can include a total workload count for each module? Thought that'd be a nice thing to have.
9 (commented on others PR)
Hmm "increaseCorrect" kind of confused me on the purpose of the method. Maybe increaseWorkloadDistribution suffices. But not a big problem!
10 (commented on others PR)
I thought this implementation is quite nice. Good work!
11 (commented on others PR)
like the defensive code!
12 (commented on others PR)
maybe its better to keep useful comments?
13 (commented on own PR)
Okay will do 😃
14 (commented on own PR)
Yeah u right, I think maybe git pull doesn't record the changes properly?
15 (commented on own PR)
oops
16 (commented on own PR)
I thought the initial checkstyle rules stated that a space is needed before the brackets
17 (commented on own PR)
sure!
18 (commented on own PR)
will implement after we all agree on this new feature in meeting 😃
19 (commented on own PR)
resolved 😃
20 (commented on own PR)
resolved 😃
21 (commented on own PR)
resolved 😃
22 (commented on own PR)
yea haven't added. Resolved now 👍
23 (commented on own PR)
haha
24 (commented on own PR)
yeah. This will only happen when u manually edit the json file with module codes which are not supported. So the tasks with invalid module codes will just be ignored
25 (commented on own PR)
Agree! Will resolve now
26 (commented on own PR)
All resolved!
27 (commented on own PR)
Yep! Resolved 😃
28 (commented on own PR)
ah right!
29 (commented on own PR)
resolved 😃
30 (commented on own PR)
yep all resolved 😃
31 (commented on own PR)
hmm but what do we assert here? As in assert(?)
32 (commented on own PR)
Ah.. I see. I think it works let me change it
33 (other comment)
Close PR to prevent merging into team repo
34 (other comment)
Merge to include image in docs/images
35 (other comment)
lgtm!
36 (other comment)
lgtm!
37 (other comment)
lgtm!
38 (other comment)
Resolve merge conflicts.
39 (other comment)
I also commented out a chunk of code for 2 tests, pls ignore, I will either add or remove them according to our next discussion 😃
40 (other comment)
lgtm
@DrWala (11 comments)1 (commented on others PR)
Should this part be reflected via an optional frame, or should the fact that it was successfully executed be an underlying assumption? Maybe the branch here is better explained through an activity diagram, and the sequence diagram should show the "Happy path"? What do you think?
2 (commented on others PR)
I think there's a typo here, it should be AddressBookParser
3 (commented on others PR)
It might be helpful to add a note saying that this function does interact with storage, but you've omitted it here for brevity.
4 (commented on others PR)
Would it be helpful to future readers to show that the isRecursiveKeyword and isReservedKeyword check is also done in this process?
5 (commented on others PR)
Please remove the comments.
6 (commented on others PR)
Perhaps it would be helpful here to link to the cascading impact on commands like rdel, redit, odel and oedit, which will need to be modified to block editing until deallocation happens. It would help explain the design decisions made on those commands.
7 (commented on others PR)
Just a syntactic/clarity thing: Perhaps update the sentence to say "Run dealloc on the resident you are editing first." and then provide an example command
8 (commented on others PR)
I think the formatting of this should reference AB3: https://se-education.org/addressbook-level3/DeveloperGuide.html#design-consideration
9 (commented on others PR)
For consistency with other activity diagrams, perhaps state the actual condition in the "happy flow" and "else" for the flow that terminates.
10 (commented on others PR)
Could you add a clarification here whether the name match needs to be an exact match or not? And does it have to be case sensitive? Would be a useful caveat to have for users of the system who may not be 100% familiar with the implementation of the function.
11 (commented on others PR)
Same as above for this dealloc
12 (commented on own PR)
Done, thanks for pointing that out
13 (commented on own PR)
Done, thanks for pointing that out.
14 (commented on own PR)
You're right, I have updated it in the commit below.
15 (commented on own PR)
Done
16 (commented on own PR)
Done
17 (other comment)
Agree with Colin. We should discuss this at the next weekly standup.
Beyond that, LGTM.
18 (other comment)
Thanks for catching this, seems like we all missed it.
19 (other comment)
I've also added a destructor to show when the AddRoomCommandParser goes out of scope
20 (other comment)
@colintkn could you specify under exact match to also indicate that it has to be case sensitive? Don't want people playing with words during the PE on this.
21 (other comment)
This method has been removed. Perhaps we can close this?
@JoelHo (11 comments)1 (commented on others PR)
This should be at heading level 3 to be consistent with the document.
2 (commented on others PR)
This should be in the quotes to match the other "examples" you changed.
3 (commented on others PR)
Should this be in a different format to match the other "examples"? Additionally, perhaps the newline is not appearing as intended?
4 (commented on others PR)
Should price be Optional>Price>, similar to driver?
5 (commented on others PR)
STUD->STUB
6 (commented on others PR)
Perhaps this chunk could be simply passenger.getDriver.map(x -> x.equals(driver)).orElse(false)
7 (commented on others PR)
This should be in the constructor
8 (commented on others PR)
NullPointerException is probably the wrong exception to throw
9 (commented on others PR)
Should this be indices/indexes?
10 (commented on others PR)
Should we implement it like this (i.e. delete the passengers at index until we hit one with a pool, ignore the rest)? Perhaps a better implementation is to delete all that don't have a pool then error at the end. Also, I think it would be more intuitive if we printed the deleted passengers names rather than size.
11 (commented on others PR)
Would it be better to use argmultimap here rather than implement a custom parser?
12 (commented on own PR)
Fixed in commit 1c344c7.
13 (commented on own PR)
Fixed by commit 0c1b0db on PR #78
14 (commented on own PR)
This method is used to ensure we don't create a "duplicate" pool, so if we checked for passenger equality, the same driver could potentially be driving 2 pools at the same time as long as the passengers were different.
15 (other comment)
Hi @vvan-essa, I believe you have the wrong team repo, this is for W10-1 (i.e. G01 - Team 1). Perhaps you can check your team here.
16 (other comment)
LGTM
17 (other comment)
LGTM
18 (other comment)
LGTM
19 (other comment)
LGTM
20 (other comment)
Closed by #31
21 (other comment)
Closes #43
22 (other comment)
Closed by #41
23 (other comment)
Closed by #73.
24 (other comment)
Closes #59.
25 (other comment)
Closed by #76.
26 (other comment)
Closes #58.
27 (other comment)
Closed by #60
28 (other comment)
Removed most traces of AB3. Remaining traces will be left as-is.
29 (other comment)
Closed by #103
30 (other comment)
Closed by #103
31 (other comment)
Closed by #103
32 (other comment)
Closed by #96.
33 (other comment)
Closed by #125
@picasdan9 (11 comments)1 (commented on others PR)
Is there an extra 'the' in the second sentence; 'determines that the the command called is...'
2 (commented on others PR)
Should the 'ParseException' be formatted as code i.e. enclosed by ``
3 (commented on others PR)
Should AddressBook be StudentBook?
4 (commented on others PR)
Do we wanna indicate the multiplicity here? Is it 1-1?
5 (commented on others PR)
Correct me if I'm wrong, does this mean a student can have 0 or many school residences? Shouldn't it be only 1 school residence for every student?
6 (commented on others PR)
Have you not merged with the latest master branch, to reflect the new DG?
7 (commented on others PR)
Should you use the method StudentBook::isExistingMatricNumber that yien implemented for this instead? Also do we need reference-type Boolean or is boolean sufficient?
8 (commented on others PR)
Is there a reason you use LocalDate and LocalTime here instead of String?
9 (commented on others PR)
Do you think it would be better to abstract, this check for whether the target appointment to edit exists, as a method in Model? So that the Logic component doesn't access the internal structure of Model directly.
10 (commented on others PR)
Is the check for whether the student exists necessary, as the existence of the appointment implies that the student must exist? Or do you consider this as defensive programming? Does it mean if the Model happens to have an appointment that corresponds to no student, this appointment cannot be edited?
11 (commented on others PR)
Correct me if I'm wrong, shouldn't CommandException be thrown only in the Logic component?
12 (other comment)
What do you think if we remove this line?
I thought more about this and wonder if this is a self-invocation, which entails calling another method of its own instance. If we remove this line then it would be that AddressBook is activated by the method call addPerson() from Model, then returns and gets deactivated.
Also can you update the image in DG to match the new sequence diagram?
13 (other comment)
LGTM
14 (other comment)
LGTM
@AiwassPrime (10 comments)1 (commented on others PR)
Err..is this space suppose to be there?
2 (commented on others PR)
I think one more test for "tag does not exist"?
3 (commented on others PR)
An empty line between description and parameter section. According to CS2103T coding standard.
Similar issues in the rest of code.
4 (commented on others PR)
Empty line here.
5 (commented on others PR)
Here
6 (commented on others PR)
Here
7 (commented on others PR)
Here
8 (commented on others PR)
Here
9 (commented on others PR)
Here
10 (commented on others PR)
Should there be some test for execute?
11 (commented on own PR)
Nice suggestion, updated!
12 (commented on own PR)
Fixed.
13 (commented on own PR)
This is what I thought and planned to do, but I implement this way is to achieve consistency with editCommand.
14 (commented on own PR)
Updated
15 (commented on own PR)
I have changed this to addTwoTags.... In this case, two and multiple have no difference, and adds a set of methods just for this test is a bit.. wasteful?
16 (commented on own PR)
Updated with javaDoc
17 (commented on own PR)
Documentation (UG) updated
18 (other comment)
YEY!
19 (other comment)
This is done!
20 (other comment)
Done
21 (other comment)
Done!
22 (other comment)
Any task without a startTime cannot be recured
23 (other comment)
#103 is related to this, after command out #103. Bug seems to be fixed. Please check this!
24 (other comment)
Fixed.
25 (other comment)
Fixed.
26 (other comment)
Nice! LGTM although I recommend adding OptionalFieldTest unit tests.
It is implemented.
27 (other comment)
Now can delete recur and startTime by using editCommand (just like tags).
Example: edit 1 a/
This will delete the startTime of task 1.
28 (other comment)
hmm i definitely agree with you that we shouldnt stay in the middle.
When implementing the recur command, I thought it was a good to have a command on its own because:
- Personally, i would have more 'one-time' tasks than recurring tasks if im using a a task manager. E.g. we would only have 1 assignment 1 in a module. So for recurring tasks, realistically speaking, it should be made into a command rather than just a normal field like 'workload' for example. This is also a justification we can give for the criticism on 'why does recur have to be a command on it's own' if we get it?
- With regards to your 1st problem, I am not quite sure as to why the book will stop updating weekly? If a task is recurring weekly, it will refresh the deadline every week regardless, no? Might need some clarification there haha sorry
- The second scenario is actually a v important consideration. One possible implementation can be when a user marks task as done, we can update the deadline (and remove starttime maybe), so that the user can see the next deadline already? what do you think? Another possible solution would be to maybe add a next deadline: field in the task card which is way simpler i think?
For the refresh command, i think it is a bit unsafe to add a new command with only a day left because I think quite a few changes would need to be made? and we only have (only a day at most) to implemement the feature? I am scared that it will be too tight for v1.3 deadline?
Overall, I am still fine with either though cuz for me, both ways work fine and (i think) either way can be justified hahaha
For 1, I think your justification is also valid, maybe need a vote?
For 2, let's say you added a task whose deadline is 2021-4-1, recurs daily, and then you close the software. After two months, you open the software again, it will become 2021-4-2. But if you do not enter any command and close the software straight away, the storage will not be updated, it is still 2021-4-1.
29 (other comment)
Missing UGDG update, other than that LGTM
Yup, I did not get consent from anyone to add this feature. Just put it here first, if everyone thinks this is good. Then I will update those.
@CSmortal (10 comments)1 (commented on others PR)
change to "different predicate" line 37
2 (commented on others PR)
change to "different command" line 53
3 (commented on others PR)
could add a few more tests just to be safe, for both failure and success, maybe something like "ModuleTutorial" for user input and predicate is {"Module", "Tutorial"}?
4 (commented on others PR)
change the comment to "// missing description prefix "
5 (commented on others PR)
change comment to "invalid description"
6 (commented on others PR)
Following the comment, the assertParseFailure() in line 115 should have 2 invalid values. Can change either the description or date to an invalid value
7 (commented on others PR)
similar to a previous comment, should change the description to an invalid one
8 (commented on others PR)
i think there should be a test for parsing with invalid args
9 (commented on others PR)
I think it would be better code quality wise to add an else if clause for CommandResult.isUncompletedTab, then the else clause throws an assert false
10 (commented on others PR)
Nice use of assertions!
11 (commented on own PR)
ParseExceptions are thrown in line 59 and line 64 for unexpected user input, my assertion in line 57 was mainly to warn whoever make changes to our code against using this public method. It should only be called if the user's argument input passes #hasMultipleValidIndex first, as seen in line 31 of DeleteMultipleCommandParser and line 59 of TaskifyParser.
12 (commented on own PR)
Sorry, can I clarify which line you are referring to?
13 (other comment)
Close #9
14 (other comment)
I think it is. However, you will need to use the exit command so that the storage saved the latest updated task list
I'm not entirely sure, but i dont think we need to use exit command? For the test, can't we just instantiate a new TaskifyStub and then check if its tasks are sorted?
15 (other comment)
could add a few more tests for parsing using TagSearchCommandParser. Have a few additional comments too
By additional comments, do you mean comments to explain the tests?
I'm referring to changing the comments for line 37 of TagContainsKeywordsPredicateTest and line 53 of TagSearchCommandTest (just the first two reviews for this PR)
16 (other comment)
Duplicated issue
@github-amanda (10 comments)1 (commented on others PR)
Maybe can use StoreMando instead of storemando
2 (commented on others PR)
Instead of “value”, maybe you can change the variable name to “date”
3 (commented on others PR)
Maybe you can use StoreMando instead of storemando for consistency
4 (commented on others PR)
Agreed
5 (commented on others PR)
Would "expiry date" be better than "expiryDate"?
6 (commented on others PR)
Maybe it will be clearer to put it as "2nd item of the current list" as user may think that it is the overall list.
7 (commented on others PR)
"sort quantity asc" is now the updated command for sorting items in ascending order of quantity. There is also the "sort quantity desc" command for sorting items in descending order of quantity. You may want to update this! 😃
8 (commented on others PR)
Just a minor concern, but does the number of spaces matter? e.g. Will 'Room Living ' match 'Living Room'?
9 (commented on others PR)
I think both are fine. Since it's just an additional word, I think it's ok to leave it as it is!
10 (commented on others PR)
Just a minor language error, "is neither day(s) or week(s)"
11 (commented on own PR)
ok
12 (commented on own PR)
Please look at the updated version. I have modified the sample names, they are now in alphabetical order.
13 (commented on own PR)
Yes, this will not work, and it is supposed to be that way. This follows the "add" command, where location "bed (lots of whitespaces) room" is considered a different location from "bed room". Hence, when I clear items in location "bed (lots of whitespaces) room", items in location "bed room" will not be deleted.
14 (commented on own PR)
Noted, I have changed the method name to parse_emptyArg_returnsClearCommand()
15 (commented on own PR)
I think this is a good suggestion, but not a compulsory implementation since the current implementation is still a workable product. Maybe we can do this in the coming iteration.
16 (other comment)
looks good!
17 (other comment)
#10
18 (other comment)
LGTM
19 (other comment)
looks good
20 (other comment)
LGTM!
@Cheng20010201 (10 comments)1 (commented on others PR)
should be flashcards
2 (commented on others PR)
need a new line at EoF
3 (commented on others PR)
Can we turn isNotAns to isAns and flip it inside the method? A bit counter intuitive to read haha
4 (commented on others PR)
This file (and some other docs) are like no longer needed but for now we just keep them for references bah haha
5 (commented on others PR)
Perhaps this part can be applied abstraction on? Now the code is getting more and more imperetive haha
6 (commented on others PR)
should remove this file (user local storage)
7 (commented on others PR)
I think the .gitignore needs to be modified s.t. data/* won't be version controlled. Previously it was working but now due to some refactoring issues it no longer ignores.
update: (fixed jn)
8 (commented on others PR)
LGTM but having a separate method like:
public static Flashcard[] getDatabaseOfFlashcards(int numberOfQuestions) {
return Arrays.copyOfRange(getDatabaseOfFlashcards(), 0, numberofQuestions);
}
is nicer as my pending PR has many tests related to this method so I would imagine there would be lesser conflicts if you have the above instead. Thanks!!!
9 (commented on others PR)
lgtm if we don't potentially need more booleans for CommandResult (do we?)
10 (commented on others PR)
It would look fancier if we add descriptive words before users; E.g. as a dilligent user/learner or sth?
11 (commented on own PR)
should be json array of all tags of one single flashcard
12 (commented on own PR)
Originally that Interface is to help with a generic method to change the content of flashcardListPanelPlaceHolder. Now the current version it is no longer needed. Will fix it thanks!
13 (commented on own PR)
This is the dummy history data generation part. Since (now the Score handles the LocalDatetime which is the Score's creation time internally) && (The precision of LocalDatetime is only limited to seconds in our application), a consecutive creation of Score object will result in duplicate Score objects stored (which, by the same principle of how we store Flashcards, will throw an exception).
When the data is no longer dummy, we can safely assume the user would at least take 1 second between finishing the current quiz and finishing the next quiz.
If the above is not a legitimate assumption, I can change my implementations (but some efforts are required).
14 (commented on own PR)
I forgot since the entire test class is ... dummy :>
Will change it back.
15 (commented on own PR)
It is essentially because
int index = -1;
if (isShowingHistory) {
index = flashcardListPanelPlaceholder.getChildren().indexOf(flashcardListPanel.getRoot());
if (index != -1) {
flashcardListPanelPlaceholder.getChildren().set(index, scoreHistoryListPanel.getRoot());
}
}
the
indexOf(...)
method would return -1 if the object to look for is not in the List.
Thus a static variable seems not very ok but I kind of cannot think of any elegant solution to it...(?😬)
16 (other comment)
Wrong PR chosen. Sorry.
17 (other comment)
The weblink for the previously updated README.md is also incorrect (cs2103t -> cs2103 in url, at line 16), please change it as well. Thanks!
18 (other comment)
Closed #8
19 (other comment)
This PR will be made as draft until we formally assign tasks for members on 28th Feb.
Reason: to link with issues created after that
20 (other comment)
The deadline is soft 👀
21 (other comment)
This is just to 'figure out', so after you know what is going on you can just self-close it or create a draft PR containing the experiment you ran with the code base.
22 (other comment)
This is just to 'figure out', so after you know what is going on you can just self-close it or create a draft PR containing the experiment you ran with the code base.
23 (other comment)
This is just to 'figure out', so after you know what is going on you can just self-close it or create a draft PR containing the experiment you ran with the code base.
24 (other comment)
igtm~ probably should merge this first then merge the flashcard class? because classes like phone etc dont exist anymore and not sure what would happen if we merge into that
😮 I will try to merge your flashcard class first; this one is less dependent on other stuff so should be relatively easy.
25 (other comment)
@xyzhang00 Some simple modifications are needed for README.md as per W7 tasks. お願いします!
26 (other comment)
I suggest since commands like
AddCommand
ClearCommand
DeleteCommand
EditCommand
FindCommand
are probably not of our concern here, can I try experimenting to remove them? @Jellybeano This will make morphing slightler easier 😃
27 (other comment)
Added greetings message for the app.
Perhaps create a PR for it, as it will probably be something useful for the application? 😃
28 (other comment)
Will close it for now, perhaps will reopen and discuss how to properly merge this during team meeting.
29 (other comment)
Will close it for now. Perhaps will discuss later how to merge it during team meeting.
30 (other comment)
@xinweit after I merged my previous PR into the code base there seems to be a conflict. The conflict is in MainWindow.java and it seems its relatively simple to resolve from your side. Its a bit troublesome from my side as I would need to make changes of your PR locally, so can help?
You can resolve it by trying to pull the latest master branch to your GUI-display branch. Thx!! 😃
31 (other comment)
Just clarify: is it clear now where can this Mode class be potentially useful (i.e. help change the mode of display)?
32 (other comment)
GJ!!
33 (other comment)
With this commit the GUI now magically can differentiate between learn mode and quiz mode display. But the modification here is only tentative (and far from elegant) and mainly to provide some idea of how GUI works; to further support the next and check feature, more work needs to be done.
34 (other comment)
Looks like this PR shares a common commit history with previous one, is this intended?
35 (other comment)
Err so this PR is a super set of your PR 74 and 76? Sorry I am a bit confused
36 (other comment)
lgtm!
...
37 (other comment)
The pr is on thank you @xyzhang00
38 (other comment)
(hopefully) no need to add any new features
39 (other comment)
Apologies :_)
@tlylt (10 comments)1 (commented on others PR)
The reason for updating the endpoint card later is because?
2 (commented on others PR)
A possible future refactor could be moving the animation to CSS and have it triggered at the start of execution and end when the result returns. But this is decent at this stage.
3 (commented on others PR)
Small typo in the comment, should be a post request
4 (commented on others PR)
Perhaps timeout could be extracted out as a static constant to avoid magic number issues?
5 (commented on others PR)
perhaps can consider using an actual valid url? This example seems fake.
6 (commented on others PR)
I suppose the comment is outdated? as it refers to phone, email and address?
7 (commented on others PR)
is MainStreet a valid address?
8 (commented on others PR)
the comment is wrong?
9 (commented on others PR)
Is it necessary? because is Address.ValidAddress already invokes isUrlValid method within in it
10 (commented on others PR)
Perhaps can logger.error or logger.warning here?
11 (commented on own PR)
Alright will remove the two
12 (commented on own PR)
Thank you, resolved in my updated commit
13 (commented on own PR)
Thank you, resolved in my updated commit
14 (other comment)
Looks good! 😄 Just a small note, the image and portfolio name needs to match the github handle.
Thanks! Didn't realize this is required. I have renamed accordingly.
15 (other comment)
@tjtanjin When rendered as HTML it looks like this:
16 (other comment)
@tjtanjin FYI I will experiment with this for an hour or two now. If anything I will update this thread.
-update1
Use of Platform.runLater(new Runnable() { ... can schedule the execution and update of GUI to a later stage. But right now there is still some lack before displaying Running test and it does not seem to return immediately, which means the place to invoke the call seems to be important and needs to experiment more on this.
17 (other comment)
LGTM 😃 Just a trivial point that the comment for
endpointattribute inCommandResultis the same asisApiResponse.
Good catch. Fixed and will now merge.
18 (other comment)
Great job, while you are at it, could you reduce the 5-second delay that emulates the wait time of an API response 🥺
Curious:
- how did you fix the lag?
- if we are disabling the user's ability to input while running the request, wondering if it will be better if we still show what he entered in the command box and clear it after the request is done? Not sure if this is the case already... for discussion only
- I'll make a PR really soon to remove the wait time :3
- Shifting
Platform.runLaterabove the sleep code removed the lag (which came from the initial 1 second sleep)
- Yup the entered command stays in the command box when frozen 😄
Alright cool, I guess it's the sequence of calls that messed up the thing.
19 (other comment)
Damn, I am eating my own poison... will fix this when I am home using my desktop...
20 (other comment)
Sample endpoint 3 periodically returns an empty result with the following error:
"JavaFX Application Thread" java.lang.StackOverflowError
There is no known way for the user to directly cause it as of the time of writing this. It seems completely random. What is worth pointing out is that sample endpoint 3 returns a
very long json resultwhich is also reflected in the extra 1 second it takes to load the result into display.
This seems to be a performance issue and we should consider how to address this as soon as possible.
Have tried a few times and wasn't able trigger it, if it is a peculiarity with regards to this API, perhaps we should remove it as of now.
21 (other comment)
interface as in the screen?
22 (other comment)
I would prefer to remove it i.e. maximize the space by expanding the result display. This is to keep the UI simple and more consistent by ignoring screen size differences, which might be error-prone because we need to cater to various sizes. Just my 2 cents.
23 (other comment)
I think this is a great suggestion which I suppose you have specified in #203, let's put it in 1.2b or future milestones...
24 (other comment)
Given that we can also retrieve the status phrase from response.getStatusLine().getReasonPhrase(), perhaps we can have a hover over effect that when users hover over the status, they can see the textual response phrase.
25 (other comment)
Perhaps we could try it out and determine if it makes sense visually. My hope is that it should not be displayed in such a way that clutter the essential information that we are trying to show.
26 (other comment)
If the length of response is a concern, perhaps we can check the response length and limit that to a reasonable number such that we display a proper error message when the length exceeds that.
27 (other comment)
I think this might be a UI tweak/task where we explore better ways to the layout of the response(both what we extracted out and the actual response entity-body of the API request). Maybe anyone who has thoughts of how our UI could be improved can have a go at this?
28 (other comment)
Let's start adding required tests as issues to be fixed by 1.2b so that we don't ignore them anymore:)
29 (other comment)
Ok I think I need to see how find command works first
30 (other comment)
Seems like it's fixed, @ong6 can verify again.
31 (other comment)
@tjtanjin the run and send test lowly unreliable they sometimes pass sometimes fail on my comp and I couldn't even commit my work on sourcetree.
Yes @JulietTeoh if run & send have issues, please include in the error message so that I can take a look 👁️
32 (other comment)
A link to a video on RESTful API is included in help window by #300
33 (other comment)
I agree with your observation, though instead of removing the menu bar outright, I feel that we can replace it with a banner saying History and Response, much like your original UI mockup. We can discuss this tomorrow along with other UI tweaks we can make this coming week.
Great suggestion, let see what others think tmr
34 (other comment)
Codecov Report
Merging #327 (0e3a546) into master (a276db4) will decrease coverage by
0.07%.
The diff coverage is
100.00%.
@@ Coverage Diff @@
master #327 +/-
============================================
- Coverage 67.99% 67.91% -0.08%
- Complexity 557 554 -3
============================================
Files 100 100
Lines 2037 2032 -5
Branches 202 201 -1
============================================
- Hits 1385 1380 -5
Misses 588 588
Partials 64 64
Impacted Files Coverage Δ Complexity Δ
...n/java/seedu/us/among/model/endpoint/Endpoint.java
96.51% <ø> (-0.20%)23.00 <0.00> (-3.00)
...ava/seedu/us/among/logic/commands/EditCommand.java
96.15% <100.00%> (ø)12.00 <0.00> (ø)
...du/us/among/model/endpoint/UniqueEndpointList.java
92.85% <100.00%> (ø)21.00 <0.00> (ø)
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered by Codecov. Last update a276db4...0e3a546. Read the comment docs.
Dude I deleted a bunch of lines and coverage decreased?
35 (other comment)
Closed by #393
36 (other comment)
Anyone is currently working on this? If not I chop first...
37 (other comment)
Is this going to be added in the form of a new feature?
yes, I am thinking of upArrow to retrieve the last command.
38 (other comment)
If this gets added before the night can update the UG as well? 😄
yea sure
39 (other comment)
@tjtanjin After this PR I have nothing else to add for UG, feel free to submit tonight 😃
40 (other comment)
There are a few areas where we need to address, at least base on the coverage analysis report by IntelliJ. While some areas such as UI could be disregarded, we should try to cover those cases in Logic, Model, and Commons, possibly discuss further on specific work allocation in the afternoon meeting
41 (other comment)
Possibly discuss the progress on this task in the afternoon meeting. From my perspective, I think the UG styling & structure are of decent quality, largely thanks to @tjtanjin. If all features are finalized, perhaps everyone could go through the UG at least once again just to make sure no stones are left unturned.
42 (other comment)
43 (other comment)
Resolved after today's meeting.
@icelenaugust (9 comments)1 (commented on others PR)
Rmb to update the java doc!!
2 (commented on others PR)
Time is not a compulsory field for event right? Only date is if Im not wrong! Is it necessary to throw missing field message format?
3 (commented on others PR)
Maybe you meant Jackson-friendly adapted "task" object!
4 (commented on others PR)
in the adapted task
5 (commented on others PR)
Priority is an optional field?
6 (commented on others PR)
Rmb to edit the java doc!
7 (commented on others PR)
Maybe can edit this javadoc or can leave it when removing dependency!!
8 (commented on others PR)
Rmb to update the javadoc!!
9 (commented on others PR)
Javadoc not matching the method!! You may wanna update
@xyzhang00 (9 comments)1 (commented on others PR)
This might be violating Law of Demeter, could there be better way to abstract these type of statements?
2 (commented on others PR)
What about creating methods to switch to learn mode inside the model manager?
3 (commented on others PR)
Is the change back to AddressBookTest intentional? :0
4 (commented on others PR)
Is there a reason for calling sleep?
5 (commented on others PR)
What is this index referring to? Would it be better to set it as a static variable at the start instead of a magic number?
6 (commented on others PR)
Is there a reason for these 2 list panels to implement list panel? extending UiPart>Region> seems to be sufficient OOP for me :0
7 (commented on others PR)
I think there is a .contains() method?
8 (commented on others PR)
I think it is a valid assumption! Probably will be better to document it down in the javadoc later.
9 (commented on others PR)
Is there a need for isAllTags exist on the right side of operation?
10 (commented on own PR)
Edited, thanks.
11 (commented on own PR)
I changed it to isQuestion, hopefully this is better!
12 (commented on own PR)
Ok!
@pavz02 (9 comments)1 (commented on others PR)
Isn't toTest.isBefore(acceptableDate) sufficient haha? Because dateToday is before the acceptable date? And Also because remind is for upcoming deadlines right, you could consider making sure all the dates are after today. In case a person/order with a past delivery date is still in the system.
2 (commented on others PR)
What exactly does "in the context of the FindCommand" mean?
3 (commented on others PR)
Wait so whenever the input is an add command the request is initialised to "Give me more pineapples."?
Because you implemented request seperately and not in the add command, do you need the request in the addCommand parse function?
4 (commented on others PR)
Request only takes in the request field right? So does it need a prefix? Because it will always be r/ and never anything else.
5 (commented on others PR)
Maybe you can use toString() here instead of value
6 (commented on others PR)
So the request is like a tag?
7 (commented on others PR)
ohh icic!
8 (commented on others PR)
Do you need both isSameOrderItem and equals? You could consider using the equals method only because the same order will probably have the same cost also.
9 (commented on others PR)
Is there any reason why it should only contain alphabets? Maybe can relax it a bit for types like 12" chocolate cake or something haha
10 (commented on own PR)
There is no way two help cards will be the same because there are only a few fixed set of commands which are fixed throughout the program which is why I mentioned it. But no harm leaving it.
11 (commented on own PR)
Okay!
12 (commented on own PR)
Originally when I switched from the help page to main, I used fillPersonListPanel() in the resetMainWindow() function to fill in the vBox with the person list again, so as I was using it twice I abstracted it out. I changed it to re-using the same person list so I don't need it anymore but forgot to take out the abstraction. Do you think ts better to insert a new person list using fillPersonListPanel() or reuse the old one?
13 (commented on own PR)
yup
14 (commented on own PR)
Okay will change all the person and address book references you've pointed out
15 (commented on own PR)
Lmao okok
16 (commented on own PR)
Yup, I originally used the function to use from HelpCommandPanel to change from the help to person list there but it was quite inefficient to get everything from there so I ended up just sending a reference to the main window itself to help which is a cyclic dependency now that I think about it, oops probably have to change stuff then.
17 (commented on own PR)
Hmm the data can change because you can add orders when you are in the help page, you just cannot see them in the panel, so I think that is a better idea too thanks
18 (commented on own PR)
Oh really? Did not know that haha
I tried using a static method but it cannot access non-static variables so that does not work either
I guess I'll try the association class then, or leave it if I cannot lolol
@ong6 (9 comments)1 (commented on others PR)
You can actually use the Equals method in this same class since the equals method checks for if method, address and tags are the same.
2 (commented on others PR)
nice catch on the naming here
3 (commented on others PR)
Since we are not done with EditCommand yet, perhaps we should keep this as a to-do since when we change EditCommand it may lead to some more errors here.
4 (commented on others PR)
the space there is actually on purpose so that if you enter the commands, there has to be a space else it won't work. Unless u wanna allow them to do -xmethod
5 (commented on others PR)
wow cool diagram
6 (commented on others PR)
The grind for comments is real
7 (commented on others PR)
nice addition.
8 (commented on others PR)
why did you change this to 0?
9 (commented on others PR)
Ohh, ok nice
10 (commented on own PR)
Don't worry, I do not allow duplicate endpoints, the check is as follows -> if the method and address same it is considered as a duplicate.
11 (commented on own PR)
newline indentation must be 2 tabs wide, some checkstyle error flagged it so no choice
12 (commented on own PR)
Once again, duplicate endpoints have been considered to issues solved
13 (commented on own PR)
no, i got rid of all the tests using typicalendpointlist cause idk what they are for
14 (commented on own PR)
yea, keep this in here.
15 (commented on own PR)
nice
16 (commented on own PR)
👍
17 (other comment)
As the QA for my company, I would like to organize my tasks so that I can identify what needs to be done next
18 (other comment)
Yay
19 (other comment)
I agree with yong liang
20 (other comment)
Don't remove the List command, it shows a complete list of all the API's after the find command. There is no way to do that after the find command is run
21 (other comment)
Okie @ong6 introduced the whitespace in
PREFIX_METHODin this commit 5 days ago so I think's best for him to do the review.
@ong6 so heres a more in depth view of whats wrong with PREFIX_METHOD = "-x "
using an example of "edit 1 -x "
when passed into the parseIndex method of ParserUtil.java, it calls
string trimmedIndex = oneBasedIndex.trim(); which trims the string to "edit 1 -x".
then because PREFIX_METHOD is "-x " (with the space), StringUtil.isNonZeroUnsignedInteger(trimmedIndex) will be true, because trimmedIndex will be equal to "1 -x", which leads an exception of the EditCommand.MESSAGE_INVALID_INDEX being thrown, instead of a more specific error message from the parseMethod method.
Also, if PREFIX_METHOD = "-x ", doing "edit 1 -t " or "edit 1 -h " does not work to remove tags/header because of the same reasons as stated above.
TLDR: there should be no space in all prefixs, unless you want to change a ton of other codde
Nice spot!
But then this would allow users to do edit 1 -tdog (without space), I guess it would be possible to remedy this somewhere else, but if I'm not wrong, the original AB3 code came with a "/t " (with space) so when changing to "-t " I kept the space as well.
However, after checking out your commit, I think that the problems that the space brings are substantial so this is a good change overall!
22 (other comment)
Uhm, I just tested it. But it seems that the clear command does not show this picture? Is it only meant to be used for list when there are no endpoints?
@AhQuanz (8 comments)1 (commented on others PR)
This is used in line 20 to ensure validity of quantity
2 (commented on others PR)
Will be adding test cases for empty String
3 (commented on others PR)
Any reason why this has to be public?
4 (commented on others PR)
Not sure if I misunderstand this, but shouldn't this be for orders?
5 (commented on others PR)
Likewise , please refer to the next comment
6 (commented on others PR)
maybe we should rename this to be more a more boolean name?
7 (commented on others PR)
Don't think its a good idea to have method name similar to the field name
8 (commented on others PR)
Is the original set equals not working? I think the original equals for set do checks the individual elements according to the API.
9 (commented on own PR)
Sure. Merge his PR and then i will resolve the conflict and add in the missing actions
10 (commented on own PR)
Noted.
11 (commented on own PR)
Yeap , will merge his changes into my branch after his PR has been merged
12 (commented on own PR)
Will update in the next commit
13 (commented on own PR)
Yeap but even if dont have it's by default false.
Will add it in the next commit.
14 (commented on own PR)
Could you elaborate?
I was thinking of changing it to status : (Assigned / Not Assigned)
15 (commented on own PR)
Don't think we should do a counter, as I was thinking of setting quantity's value to be private.
16 (commented on own PR)
Sure. will be adding this in the next commit
17 (commented on own PR)
Will be making this change in the next commit
18 (commented on own PR)
Hmmm based on the doc , it should work but when i was debugging that was giving me some problems. Will look into it again.
@glatiuden (8 comments)1 (commented on others PR)
**View Tutor** | `view_tutor INDEX`, <br> e.g. `view_tutor 1`
2 (commented on others PR)
I don't think the variable appointmentList and its respective methods are required in the Appointment class, since Yuting is handling the List classes, which already have an AppointmentList.
3 (commented on others PR)
This line may not be required, as referenced to #12, Tag is not a superclass of Name, Email and Gender.
4 (commented on others PR)
I think we might need another dateTime variable here because from what I see, the tutee can only edit either the timeFrom or timeTo. If we update one of them, the another's value will be overridden due to how updatedTimeFrom and updatedTimeTo is instantiated. Maybe @kingsleykuan can double confirm on this? Thanks! The rest of the codes LGTM!
5 (commented on others PR)
This should be EditBudgetCommand instead?
6 (commented on others PR)
I think you forgotten to remove the debugging print statement
7 (commented on others PR)
I think you forgotten to remove the debugging print statement here as well
8 (commented on others PR)
You have used the Enum correctly! Just a small recommendation, sorry I kind of forget how secondary school grading works, but maybe the Enum can accepts values such as "A1", "A2" to make it as close to the real world context? Otherwise it's fine to retain as single alphabet! Not an alarming issue!
9 (commented on own PR)
Noted! Will omit during the merge.
10 (commented on own PR)
This meant to serve as a base template as I modified the styling slightly. Can choose to adopt this styling or go with the default style from AB3.
11 (commented on own PR)
Noted, I have removed it & committed.
12 (commented on own PR)
Noted, then I'll shift it back to Model for meantime. If we decided to adopt this approach then I'll reinstate back in this file
13 (other comment)
Resolved the merge conflicts and used the Ui image from the master branch instead.
14 (other comment)
Will resolve the conflicts after PR #2 is approved due to accidental merging of branches.
15 (other comment)
Noted @kingsleykuan, will proceed to merge and remove the stubs in a followup PR instead since there shouldn't be any interference with the rest of the codes.
16 (other comment)
In meantime, please also try to fix the build error (I think it's located in the test cases) as we have turned back on the blocking of merge if there's any build error.
17 (other comment)
Fixed merge conflicts and shifting of Schedule's interface methods to Model.java.
@cnlinh (7 comments)1 (commented on others PR)
It should be optional for radd so can you update it?
2 (commented on others PR)
Ah, I was referring to adding the brackets i.e. [r/ROOM] for optional tag
3 (commented on others PR)
missing javadocs?
4 (commented on others PR)
Missing param description?
5 (commented on others PR)
Missing param description?
6 (commented on others PR)
@throws NullPointerException?
7 (commented on others PR)
@throws NullPointerException?
8 (commented on own PR)
Done!
9 (commented on own PR)
Good catch!
10 (commented on own PR)
Will do in later iteration
11 (commented on own PR)
Done!
12 (commented on own PR)
Good catch!
13 (commented on own PR)
Done!
14 (commented on own PR)
Done!
15 (commented on own PR)
Done!
16 (commented on own PR)
Good point!
17 (commented on own PR)
Done!
18 (commented on own PR)
Done!
19 (commented on own PR)
Done!
20 (commented on own PR)
Done!
21 (commented on own PR)
Done!
22 (commented on own PR)
Done!
23 (commented on own PR)
Done!
24 (commented on own PR)
Done!
25 (commented on own PR)
Done!
26 (commented on own PR)
There is only one field so field is chosen
27 (other comment)
LGTM
@kingsleykuan (7 comments)1 (commented on others PR)
This update is no longer required as it was changed in another pull request, can revert to the current master revision.
2 (commented on others PR)
Sorry I think there was some miscommunication as I also updated the user stories! When merging you can see if you want to keep your version or mine, your version looks good as well.
3 (commented on others PR)
Is this use case not completed yet?
4 (commented on others PR)
Is this precondition required? I think it is fair to assume that a list always exists and it might just be empty.
5 (commented on others PR)
Can move to either the parent package model or to a new package model.appointment
6 (commented on others PR)
Sorry small change needed here, I made the AppointmentDateTime parsing follow more closely with the user guide so an AM/PM is required now. Setting to 12:00AM instead of 00:00 should work.
7 (commented on others PR)
I am slightly concerned about having Model extend ScheduleModel in terms of design, but I understand why it's done this way for abstraction and to maintain compatibility. If there is no better solution then it LGTM. Perhaps in a future PR we can abstract the different model interfaces out (for tutor, appointment, etc) and then have Model extend all of them for consistency.
8 (other comment)
Please restrict pull requests to only the required changes. This pull request includes tutorial code as well as other code updates which is inappropriate for updating the developer guide.
9 (other comment)
While I really appreciate the creation of the new class AppointmentBook and the other changes, I must warn against these kinds of monolithic PRs. At the current moment there are too many changes to look through and accept, and I am unsure how some of these changes will affect other aspects of the code. I worry that with the amount of changes made we may be unable to fix all the test cases by this week's deadline.
May I suggest splitting this PR by creating new branches and cherry picking the relevant commits?
10 (other comment)
Duplicate, resolved by #126
@pngsebastian (7 comments)1 (commented on others PR)
List>Appointment> should be replaced with ObservableList>Appointment>
2 (commented on others PR)
You can create a MESSAGE_INVALID_APPOINTMENT_DISPLAYED_INDEX to replace MESSAGE_INVALID_PATIENT_DISPLAYED_INDEX here.
3 (commented on others PR)
This should be replaced with
'(patient.equals(toCheck.getPatient())
|| doctor.equals(toCheck.getDoctor()))
&& getTimeslot().hasOverlap(toCheck.getTimeslot());'
4 (commented on others PR)
docs to update to EditAppointmentCommand.
5 (commented on others PR)
I don't think this is needed since it functions the same as hasAppointment method.
6 (commented on others PR)
I don't think this is needed as it functions the same as contains.
7 (commented on others PR)
I don't think this is needed as it functions the same as hasConflict.
8 (commented on own PR)
Yes, it is intended to be in the format of delete-patient --force INDEX, which is indicated in FORCE_DELETE_MESSAGE_USAGE. Will edit the javadocs so that it's clearer.
9 (commented on own PR)
Yes I think it might not need to be in the try block, will edit later. The reason why I wrote isForceDelete is to avoid the possibility of isForceDelete being not instantialized. Another way is shifting the try block inside the first if statement, which may be a little ugly, almost arrowhead style. What are your thoughts?
10 (commented on own PR)
The reason why I do it this way is so that if the index is wrong for delete-patient --force notAnIndex, the parseException will be raised as well. I will add in an invalid index message before the message usage to improve on the clarity of the exception.
11 (commented on own PR)
My bad, missed out on this one
12 (commented on own PR)
Meant to align the tail of the comment, will commit the changes.
13 (commented on own PR)
I don't think an exception is needed as indexToParse = args by default, so aisjdhabakahbakshdbankdjashb 1 will be captured as a ParseException when ParserUtil calls parseIndex on it.
@marcusleeeugene (7 comments)1 (commented on others PR)
Good use of assert statement here!
2 (commented on others PR)
Plural form here helps to identify the multiple values available, good job!
3 (commented on others PR)
There's a redundant new line here, can remove if not required.
4 (commented on others PR)
Good use of for-each loop, its very readable!
5 (commented on others PR)
Good use of ifPresent!
6 (commented on others PR)
Rating is from 0-5
7 (commented on others PR)
Not sure if your revert worked correctly, because my implementation was initially HashMap. I'll merge in yours probably the last since it already takes in my new changes.
8 (other comment)
Duplicate Issue that has already been created.
9 (other comment)
Duplicate Issue that has already been created.
10 (other comment)
Task Complete.
11 (other comment)
Completed Task.
12 (other comment)
Completed Task.
13 (other comment)
Feature already implemented in AddressBook.
14 (other comment)
Already implemented in AddressBook.
15 (other comment)
Completed.
16 (other comment)
Completed.
17 (other comment)
Tutorial, not required to merge.
18 (other comment)
Tutorial, not required to merge.
19 (other comment)
Tutorial, not required to merge.
20 (other comment)
Tutorial, not required to merge.
21 (other comment)
Sorry, i pull requested to the wrong team project.
@YuFeng0930 (7 comments)1 (commented on others PR)
Sochedule?
2 (commented on others PR)
No need to check null?
3 (commented on others PR)
Maybe consider YYYY-MM-DD (all upper, instead of partially upper), then hh:mm (all lower)
4 (commented on others PR)
Should this be removed or it's waiting for model dependencies removal?
5 (commented on others PR)
I think for user, "YYYY-MM-DD" would be better, as "uuuu-MM-DD" is lower level stuff.
(Side info: "uuuu-MM-DD" can deal with leap year 0229 problem, generally speaking, it's just a strict version of "yyyy-MM-DD")
6 (commented on others PR)
The exampleDate can consider to be put in CommandTestUtil as a constant, otherwise, it looks like magic number.
7 (commented on others PR)
Once these magic dates are put in CommandTestUtil, you can just import and use them without initialising them again.
8 (commented on own PR)
Thanks for spotting the error:)
9 (other comment)
Yeah I think Deadline should under Task package. LGTM:)
10 (other comment)
Can these changes can pass all the current unit tests?
It didn't pass, since the unit tests now are mostly old ones that haven't been updated yet.
11 (other comment)
Need to enable four tests in AddTaskCommandParserTest and AddEventCommandParserTest
12 (other comment)
Yeah correct, now is like user can't even input the thing and stuck there
@lue97 (7 comments)1 (commented on others PR)
Perhaps you could condense this to the same line
2 (commented on others PR)
This validation allows invalid dates like 99-99-2021. Perhaps you could check it with DateTime classes or use #41 dateUtil?
3 (commented on others PR)
This may not work for stuff like tar.gz
4 (commented on others PR)
This might be an extra space
5 (commented on others PR)
Move these to FileUtils?
6 (commented on others PR)
Inconsistent spacing between command format and >br>...
7 (commented on others PR)
Line 286 should be: Advanced users are welcome to update the data directly by making edits to these files.
8 (commented on own PR)
I'd like to keep Goal as a class that store frequency and not associate it with meetings. I'll just change it to getGoalDeadline or something.
9 (commented on own PR)
It's updated as a binary file with the same file name.
10 (commented on own PR)
Maybe use logger instead?
My bad that was supposed to be removed
11 (commented on own PR)
That is intentional
@DarkDestry-t (7 comments)1 (commented on others PR)
Was this always there as a duplicate since the initial commit?
2 (commented on others PR)
Missing Equality Check test
command = 1 -> false
command = null -> false
command = new command of same parameter -> true
command = same command -> true
command = different command -> false
3 (commented on others PR)
Missing checks
predicate = 1 -> false
predicate = null -> false
predicate = same predicate object -> true
4 (commented on others PR)
You missed the Same object check
5 (commented on others PR)
Hmm not sure why test coverage missed it but I guess its fine.
6 (commented on others PR)
Do either of the following
Sort the collection again in the test case and compare element by element
Use the string comparator to compare every element with its subsequent element in a for loop
The test is to check lexicographical.
If the add command is renamed and no command starts with A, this test fails incorrectly.
If the add command remains but the list is [add, find, alias, edit, delete], this test passes incorrectly.
7 (commented on others PR)
You seem to have misunderstood my approach. This is not testing the sorting order of your getAutocompleteCommands. This is testing the sorting order of the Collections.sort function.
What you should be doing is
get a completely clean list of command unrelated to your autocomplete command.
Sort that list of commands as per your expected sorting order Collections.sort(cleanlist)
Iterate through this clean sorted list and compare against your test list
This existing test will fail to achieve its purpose when
logic.getAutocompleteCommand("") returns [add, clear, alias, find, delete]
Collections.sort sorts it into the correct order
asserts verify that its the correct order.
Note that the command actually returned a bad order but all the asserts passed.
8 (commented on own PR)
9 (commented on own PR)
10 (other comment)
closed with #39 #40 #37 #38 #41
11 (other comment)
closed as duplicate of #2
12 (other comment)
Depends on #85
13 (other comment)
Depends on #84
14 (other comment)
Depends on #85
@vuminhhieunus2019 (7 comments)1 (commented on others PR)
Avoid using wildcard import, it would be better to list all the import explicitly
2 (commented on others PR)
Should move this to the default branch of the switch statement.
3 (commented on others PR)
You can add which methods you implement for this stats command, you can refer to sort and undo/redo implementation for more details "It implements the following operations:" part.
4 (commented on others PR)
>div markdown="span" class="alert alert-info">ℹ️ Note: The lifeline for StatsCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
>/div>
Add this note under the sequence diagram to indicate the limitation of PlantUML
5 (commented on others PR)
I'm unable to see the image, you might want to check the link again
6 (commented on others PR)
Remember to add these 2 commands in the table of content.
7 (commented on others PR)
You can consider enlarge the image a little since I find the text in your sequence diagram is a bit small.
@markmcwong (7 comments)1 (commented on others PR)
Just this > **Examples** has an extra space compared to every other ones in markdown, but visual wise does not change anything
2 (commented on others PR)
Perhaps Deleting a passenger would be more consistent
3 (commented on others PR)
If I'm not wrong, the regex doesn't validate whether the number given is a negative number or not right?
maybe can do ^[1-9] at start of the pattern to make sure there's no negative sign I guess?
4 (commented on others PR)
Can also test for negative price as those should be invalid too!
5 (commented on others PR)
Thanks for the info!
6 (commented on others PR)
Maybe change the name to NAME_POOL e.g. HOME_POOL and also for other variables ?
7 (commented on others PR)
maybe can change to case PREFIX_NAME.toString() and the others also for better understanding
8 (other comment)
LGTM, all links added are correct also
9 (other comment)
LGTM
10 (other comment)
LGTM also
11 (other comment)
LGTM
12 (other comment)
LGTM
@markuz5116 (6 comments)1 (commented on others PR)
Maybe can create a constant for DateTimeFormatter, same for the output to string
2 (commented on others PR)
Some notes are bold, while others ain't. I think it would be better if it was consistent
3 (commented on others PR)
Same comment as above.
4 (commented on others PR)
maybe using toEditIndex makes its purpose more obv?
5 (commented on others PR)
Good use of constants!
6 (commented on others PR)
maybe referencing what the booleans are used for would make them clearer?
7 (commented on own PR)
TitleContainsKeywordPredicate implements Predicate. Therefore in terms of LSP, having it as Predicate would be more accurate.
8 (other comment)
Complete UiMockup image
9 (other comment)
Solved in PR #28
10 (other comment)
To delete: Address, Email, and Phone
11 (other comment)
Delete Address #63
12 (other comment)
Delete Email #64
13 (other comment)
#67 Add Exam class
14 (other comment)
#85 Add ExamList
15 (other comment)
for assignment and assignment list
16 (other comment)
add, edit, clear, find, delete, done
17 (other comment)
I can do clear, find and generaleventlist
18 (other comment)
Done for modules and persons
19 (other comment)
Clear event too
20 (other comment)
I can do clear, find and generaleventlist
clear, find and generaleventlist are done.
find is based on description
@yeoutzer (6 comments)1 (commented on others PR)
I think to follow the java coding standard, this should be changed back to listing imported class explicitly instead of the star import.
2 (commented on others PR)
Same thing here, should probably import the classes explicitly.
3 (commented on others PR)
Good work. Good use of SLAP.
4 (commented on others PR)
Thank you for changing to the correct link. Same for the others.
5 (commented on others PR)
Thank you for updating the diagram.
6 (commented on others PR)
Good job on the documentation of implementing review feature.
7 (commented on own PR)
It is okay, the documentation will be reflected as step 1 and step 2 correctly.
8 (commented on own PR)
It is okay, the user will not be able to search by multiple criteria, it will be either by question or by category.
9 (commented on own PR)
Thank you for pointing that out. I have changed it.
10 (commented on own PR)
Yes, thank you for the suggestion. I have tried changing the sequence diagram accordingly.
@noelmathewisaac (6 comments)1 (commented on others PR)
can you replace lines 1-2 with these
---
layout: page
title: User Guide
I think this is needed for the website to display UG and DG links and you removed these lines in the previous PR.
Currently, if you check the netlify build for the website, there are no links to the UG and DG
2 (commented on others PR)
Could you update the user stories to show the edit status and sort by deadline stories. Also, I think all the priorities should be High or Medium for the current user stories
3 (commented on others PR)
I think exceptions are more suitable as we are trying to figure out errors with user input
4 (commented on others PR)
Should an exception be used here instead?
5 (commented on others PR)
I was commenting on your comment on line 63 haha
6 (commented on others PR)
Ok makes sense
7 (commented on own PR)
Ok, will add! The tests I wrote so far follow the same format as the ones for the find command.
8 (commented on own PR)
The tests in TagSearchCommandParserTest checks if the parser splits on space correctly. The test you mentioned should be part of TagContainsKeywordsPredicateTest. I have added it there.
9 (commented on own PR)
Nope that was for debugging, good catch
10 (other comment)
could add a few more tests for parsing using TagSearchCommandParser. Have a few additional comments too
By additional comments, do you mean comments to explain the tests?
11 (other comment)
could add a few more tests for parsing using TagSearchCommandParser. Have a few additional comments too
By additional comments, do you mean comments to explain the tests?
I'm referring to changing the comments for line 37 of TagContainsKeywordsPredicateTest and line 53 of TagSearchCommandTest (just the first two reviews for this PR)
ohh okay 👍
12 (other comment)
would be good to test if the list of tasks is sorted after reopening the app
I think it is. However, you will need to use the exit command so that the storage saved the latest updated task list
If its too much trouble to use the exit function then just writing unit tests to see if the sorting logic works correctly would be good.
13 (other comment)
Closes #49
14 (other comment)
Closes #52
@Hzxin (6 comments)1 (commented on others PR)
Do you think we need an exam list as well since a module can take in multiple exams at the same time.
2 (commented on others PR)
If this is only for GeneralEvent, is it better to have AddGeneralEventCommand instead to be more specific and clear
3 (commented on others PR)
Perhaps can add example of the exact delete exam command
4 (commented on others PR)
maybe editIndex can be a better attribute name in this context.
5 (commented on others PR)
Possible assertions can be put here to detect null values after assigning.
6 (commented on others PR)
is there a reason to not use TitleContainsKeywordsPredicate
7 (other comment)
Update CI status, codecov, sitemap and acknowledgement
8 (other comment)
Fixes #61 #62
9 (other comment)
solves #66 #111
@edelinetenges (6 comments)1 (commented on others PR)
I like how detailed and comprehensive this is!
2 (commented on others PR)
Just a minor typo here, should be "managing your children's contacts"!
3 (commented on others PR)
Minor english issue, I think it could be "Finds all appointments with names containing any of"?
4 (commented on others PR)
Did you change this from "option" to "Option" because it's now a class? If yes, I'm not sure if it's necessary for the user to know that it's an Option class, so "option" might make more sense to them?
5 (commented on others PR)
I think you meant for this to be "FindAppointmentCommand.MESSAGE_USAGE" instead of "FindCommand.MESSAGE_USAGE" right?
6 (commented on others PR)
Message usage here is also supposed to be FindAppointmentCommand
@yutingzou (5 comments)1 (commented on others PR)
Should this be 'Tutor Tracker'?
2 (commented on others PR)
(minor) Will removing 'I can' be better?
3 (commented on others PR)
should it be 'deletes the application'?
4 (commented on others PR)
Tutor Tracker
5 (commented on others PR)
should Set>Tag> be TagList?
6 (commented on own PR)
Thank you. This part is deleted.
7 (other comment)
Thanks guys! I'll merge this PR first in order to continue adding the command and I'll make the changes based on Vinleon's suggestion later:)
@hojiefeng (5 comments)1 (commented on others PR)
Perhaps this can be named AddVenueCommand?
2 (commented on others PR)
Perhaps throwing VenueNotFoundException would be better?
3 (commented on others PR)
I think CommandException is correct for commands.
4 (commented on others PR)
Is there an issue with modifying the list while streaming it?
5 (commented on others PR)
Use removeIf instead possibly
@whatthelump (5 comments)1 (commented on others PR)
Hi @wangtao0717 I believe you should change the filename to your github_username_in_lower_case as specified on the website. Otherwise this LGTM!
2 (commented on others PR)
Hi @wangtao0717 very minor typo here, will approve when this is fixed!
3 (commented on others PR)
@awzhenyi Very minor but there is a typo (double space) between 'the' and 'user'. Otherwise, LGTM!
4 (commented on others PR)
@jaredtengsw minor but apartment should be changed to residence here!
5 (commented on others PR)
Apartments should be changed to residences
6 (commented on own PR)
@VRSoorya So booking should be its own package under model? Because I recall someone saying booking should be under residence, but I can have it in its own package if that works better
7 (commented on own PR)
This sounds sensible, I have replaced references to "Amy" and "Bob" with "Booking1" and "Booking2" respectively.
8 (other comment)
Fixes #29
9 (other comment)
LGTM! @wangtao0717 should this say 'fixes #45' or are there more changes to be made?
10 (other comment)
Addressed by #110
11 (other comment)
To clarify, the current Name class should be more restrictive in the types of symbols accepted (people's names should not have special characters such as ^) while there are no restrictions for ResidenceName (apart from only whitespaces)?
@NBH99 (5 comments)1 (commented on others PR)
The string "null" could be "no_url" as the insurance agent may not know what is a null when checking the json file.
2 (commented on others PR)
The string "null" could be "no_url" as the insurance agent may not know what is a null when checking the json file.
3 (commented on others PR)
The log message could be more appropriate.
4 (commented on others PR)
The log message could be more appropriate.
5 (commented on others PR)
The code here does not capture the error where user input "lock" has no password.
6 (commented on own PR)
Noted thanks for the review
@w-yuchen (5 comments)1 (commented on others PR)
Maybe something like clear appointment and clear property? As well as a clear all to clear everything at once?
2 (commented on others PR)
It seems weird to me that
next()forCompletionreturns aCompletion?
Since it implements Status it needs to have a next(), and Completion shouldn't lead to any new statuses anyway, so I guess it's fine to return itself? Creating new objects at a terminal step may lead to some undesirable side effects. By checking if .next() returns the same object it can even be used to check if something is calling .next() on a Completion.
3 (commented on others PR)
Very minor nitpick, but n/ here should be referring to the property name right? Would it be good to use a property name for the example instead?
4 (commented on others PR)
Will the user be able to change back to DarkTheme?
5 (commented on others PR)
i think according to the validation regex price can have cents. Should we still consider that for the price?
6 (commented on own PR)
The and here is referring to the logical AND, I think I made it quite ambiguous here. Will go change it.
7 (commented on own PR)
Wasn't thinking straight when writing this. Somehow thought this part will be combined with appointments in the future.
8 (commented on own PR)
For completeness I guess, maybe can remove.
9 (commented on own PR)
The keywords have no prefixes though, so I think a for loop like this would be more convenient.
10 (commented on own PR)
I don't think any property prices bother including the cents part though, other than perhaps after tax calculations? But anyway will go add another field.
11 (commented on own PR)
Doing that causes quite a number of tests to fail due to having hardcoded comparisons. Since most tests don't actually interact with Client or AskingPrice, it is safer to just implement a new method for properties with clients.
12 (commented on own PR)
changed to dollars + cents.
13 (commented on own PR)
I think I meant to say if the user is searching for bob, the command will search both lists for properties with client bob and appointments with Meet bob. I'm using name here since it searches for the string in the name attribute of appointments.
14 (commented on own PR)
added 313 to 315
15 (commented on own PR)
oops sry.
16 (commented on own PR)
The default keywords don't have any prefixes though.
17 (commented on own PR)
Alright sure.
18 (commented on own PR)
Alright sure. Anyway I just realised a user can search for containing all given tags by using multiple r/ parameters.
19 (commented on own PR)
Oh right eveything has prefix. Ok will go change the find name one to n/.
20 (other comment)
Need to decide on how to store housing type first before this can be implemented.
21 (other comment)
Add github actions badge
Add acknowledgement
22 (other comment)
Add use cases for everyone's own parts.
23 (other comment)
Closed as there are changes made to the branch.
24 (other comment)
15 March discussion:
Limited set of tags
Housing types
Currently not under tag but under property type
Reuse the code from addressbook
Add extra tags: bedroom and bathroom numbers, both existing as compulsary tags
25 (other comment)
What do the others think of this refactoring of
PocketEstateParser?
Looks fine to me, passing checks means the other functions are proabably not affected much anyway.
26 (other comment)
closed with #167
27 (other comment)
Closed due to another branch continuing from here.
28 (other comment)
closes #196
@tanboonji (5 comments)1 (commented on others PR)
Minor spelling mistake here.
Should be matched instead of matches.
2 (commented on others PR)
Would it be better if 60 is declared as a constant?
3 (commented on others PR)
Can I ask what's the consideration for changing .trim() to .stripLeading()?
4 (commented on others PR)
ratio spelled as ration. Guess you love outfield alot 😄 .
5 (commented on others PR)
Extra line breaks in lines 71-72 and 74-75.
6 (commented on own PR)
@oeiyiping I have actually pondered over this for some time, did some research and decided to use the same class name.
As mentioned by @justgnohUG, since they are clearly differentiable by file path, and on top of that, there is an extremely low possibility that you will be referencing both Command classes in another class, I don't see any issues.
Feel free to share your thoughts and opinions again.
7 (commented on own PR)
For this, I followed the original AB3 boolean variable name showHelp and therefore named the boolean variable showAlias.
How about changing both to shouldShowHelp and shouldShowAlias?
8 (commented on own PR)
I agree with what you have said.
Will update it, push it into the branch and request for your review again later!
9 (commented on own PR)
Update this code.
10 (commented on own PR)
There is currently no sample or default aliases data, that is why a new UniqueAliasMap() is initialised here instead.
11 (commented on own PR)
Added Javadoc for the aliases param.
12 (commented on own PR)
Updated this code in handleAlias and similarly for handleHelp.
13 (commented on own PR)
Updated this code.
14 (commented on own PR)
Updated this code.
15 (commented on own PR)
Updated this code.
16 (commented on own PR)
Updated this code and added missing Javadocs for both parseTagsExceptLast and parseTags.
17 (commented on own PR)
Will add this once I merge PR #77 into my branch.
18 (commented on own PR)
Added Javadocs for this unchecked exception.
19 (commented on own PR)
Added Javadocs for this unchecked exception.
20 (commented on own PR)
Would it be okay to refactor this in Milestone 1.3? I will raise an issue after this PR is merged.
21 (commented on own PR)
Updated the boolean variable to shouldReturnAlias.
22 (commented on own PR)
This is a temporary solution. I will be looking to change this in the next issue #97 I'm working on.
23 (other comment)
LGTM
24 (other comment)
LGTM
25 (other comment)
LGTM
26 (other comment)
LGTM
27 (other comment)
LGTM
28 (other comment)
In ModelManager, should line 107
updateFilteredPersonList(PREDICATE_SHOW_ALL_PERSONS);of
public void addPerson(Person person)method
be updated/removed to ensure the filter is persistent even after adding a person?
Other than this, everything else LGTM for
Logiccomponent.
This line should not affect the filter after adding a new person
Alright, LGTM.
29 (other comment)
Conventions are not compulsory to be added for DG and will be tracked and discussed offline. Closing issue.
30 (other comment)
Implemented in PR #76.
31 (other comment)
After testing the new prefix parsing implemented in this PR, I think there are fundamentally a few problems here, especially with the filter and alias command.
The filter command is having trouble working as intended. For example, if I want to filter by address, I would need to input filter -a with whitespace behind.
Similar, typing filter should clear all existing filters. However, without trimming the trailing whitespaces, the filter command will recognise the command slightly different and instead filter the list of persons to show just the name.
Alias commands are also having problems when parsing and checking the validity of the commands to be aliased.
32 (other comment)
LGTM
33 (other comment)
All done, closing issue.
34 (other comment)
Closing issue since it is implemented in PR #121
Not implemented in PR #121 yet.
35 (other comment)
- TODO: Missing aliases screenshot
All unfinished parts and images will be pushed back from Milestone 1.3 and updated in Milestone 1.4
@Yanneko (5 comments)1 (commented on others PR)
is it just me or is this repeated
2 (commented on others PR)
here
3 (commented on others PR)
A Japanese character/word
4 (commented on others PR)
Yes, it is needed to make sure that the boolean keeps track of the existance of all tags. Like for example if there was a tag that didn't exist, and checkIfTagExists returns false, but subsequent tags exist, the isAllTagsExist boolean will be updated to the last check made.
5 (commented on others PR)
Enters Quiz mode
6 (commented on own PR)
Imeanlike sure but maybe sometime later. This isn't gonna make or break it for us.
@ZechariahTan (5 comments)1 (commented on others PR)
It might be needed as we should allow the user to add themselves to the system regardless of whether they have been assigned a driver or not
2 (commented on others PR)
Is the toString method call required? if this Pr is just for renaming was removing the call a mistake?
3 (commented on others PR)
I think you might have to 'change delete my profile to 'delete employee profile' as the user is the HR exec now and they're managing other employee's profiles.
4 (commented on others PR)
Is it necessary to update the passenger list after adding the pool? As far as I understand there shouldn't be a change in the passenger list after pooling?
5 (commented on others PR)
Is there a better way to test if the right pool is shown instead of checking the size of the filteredlist? maybe getting the pool object from the filtered list and asserting that it equals an expected pool?
6 (commented on own PR)
Thanks for the comment! To clarify, the VALID_[VARIABLE] constants are not used as replacements for user input but rather for the personbuilder and other such utility functions during testing. As for tests concerning user inputs, the constants declared below of the form [VARIABLE]_DESC_BOB, and as they are supposed to emulate user inputs, they are of the String datatype. Hope this addresses your comment!
7 (commented on own PR)
Thanks for the comment! I will make the relevant changes.
8 (commented on own PR)
Oh nice catch! I'll make the required changes!
9 (commented on own PR)
Thanks for bringing this up. I think it might be useful as it would prevent the violation of the Law of Demeter when other classes try to call for the TripTime strings.
10 (commented on own PR)
Good point. I removed it as Intellij suggested doing so as double data types aren't nullable but I'll add it in just in case.
11 (commented on own PR)
Nice catch! I didn't think of it but I realised when testing that the \d+ already catches negative cases as "-" is not a digit and so the input string would fail the isValidPrice check!
12 (commented on own PR)
You're right. I was intending to throw the same exception that the requireAllNotNull() check in the line above it does but an illegal argument exception would be more fitting.
13 (commented on own PR)
Noted thanks for the heads up.
14 (other comment)
Resolve issue #10
@zenlyj (5 comments)1 (commented on others PR)
Good change! The addition of new lines after each component of the flashcard will help to improve readability.
2 (commented on others PR)
Should this be "This card already exists in FlashBack." instead?
3 (commented on others PR)
Should this be step 2 instead of step 1?
4 (commented on others PR)
Perhaps you should also state that the user can search by specifying both the question and category. eg. "find q/ >keyword> c/ >keyword>".
5 (commented on others PR)
Should we list out all the imports instead of using a wildcard?
6 (commented on own PR)
Great suggestion. I have updated the section accordingly.
7 (commented on own PR)
Fixed. It should show now.
8 (commented on own PR)
Added. Also fixed the broken links in the table of content.
9 (commented on own PR)
Updated, thanks for mentioning!
10 (other comment)
LGTM!
11 (other comment)
Good job! Code is written in high quality with evident use of OOP and abstraction.
12 (other comment)
LGTM! Tests are well written and have a good coverage of the Find command.
13 (other comment)
LGTM! Code is concise and easy to understand.
14 (other comment)
Looks good! Documentation is detailed and well written.
@kieron560 (5 comments)1 (commented on others PR)
Shouldn't this be under 1a? Since you type the index in step 1.
2 (commented on others PR)
Shouldn't there be a MSS for this where you state that you request for the list of events to be set to the current date?
3 (commented on others PR)
Consequently you can put this under extensions 1a 😃
4 (commented on others PR)
Can just use getFilteredEventList().size() + 1
5 (commented on others PR)
Are all these commented out test supposed to be added back in later?
@Prabhakaran-Gokul (4 comments)1 (commented on others PR)
Good job in adding both valid and invalid prices
2 (commented on others PR)
Good idea to check all the different price ranges. Perhaps consider checking for the case when the price is MAX_INT and MIN_INT as well?
3 (commented on others PR)
Good idea to hide windows!
4 (commented on others PR)
Should it be 'entry' instead of 'food review'?
5 (other comment)
Merge Gokul About us
@glennljs (4 comments)1 (commented on others PR)
Is the else supposed to return a cross instead of empty string? If not maybe change the javadoc accordingly.
2 (commented on others PR)
This is pretty inefficient I guess, can change to utilise a Set.
Set>Event> set = new HashSet>>(events);
return set.size() == events.size();
Alternatively (slightly faster time):
Set>Event> set = new HashSet>>();
for (Event e: events)
if (!set.add(e)) return false;
return true;
3 (commented on others PR)
Ok!
4 (commented on others PR)
Alright, I agree with the standardisation requirement. However, since the purpose of this PR is to implement Events, I think it is out of scope to change the UniquePersonList as well to maintain standardisation. We can start a new issue for this.
5 (commented on own PR)
Added in latest commit, multiple tags shouldn't be allowed, but can start an issue to add that functionality.
6 (commented on own PR)
This one I not sure but I think because the purpose is to list all tags then tags is better?
7 (commented on own PR)
Adopted in latest commit.
8 (commented on own PR)
Adopted in latest commit.
9 (commented on own PR)
Adopted in latest commit.
10 (commented on own PR)
Adopted in latest commit.
11 (commented on own PR)
Changed to "noNameAndNoTag" in latest commit.
12 (commented on own PR)
Adopted in latest commit.
13 (commented on own PR)
Adopted in latest commit.
14 (commented on own PR)
Adopted suggestion!
15 (other comment)
LGTM
16 (other comment)
LGTM
17 (other comment)
LGTM
18 (other comment)
LGTM
19 (other comment)
Will implement/fix find, list, tags methods
20 (other comment)
LGTM
21 (other comment)
But when invalid, do we want it to throw error? or isit better to just do nothing
I think we should throw an error so the user understands what is wrong if they try to use the feature wrongly.
@Cp-John (4 comments)1 (commented on others PR)
Should "Appointment's %s field is missing!" be "Property's %s field is missing!"?
2 (commented on others PR)
Should update the comment to properties
3 (commented on others PR)
Should empty Appointment be empty AppointmentBook?
4 (commented on others PR)
Should update address book to property book?
5 (commented on own PR)
Updated already
6 (commented on own PR)
I think it should be one command for both property book and address book? Which one is better?
7 (commented on own PR)
Ok, I got what you mean. So split the command into 3
8 (commented on own PR)
Ahhaha, this one is not implemented yet
9 (commented on own PR)
Not implemented in its class. I will try to add it later
10 (commented on own PR)
Thanks, will update it
11 (commented on own PR)
Ok, will update it
12 (commented on own PR)
Fixed
13 (commented on own PR)
It is strange that it is displayed as "9:00am" on my laptop. maybe due to java versions?
14 (commented on own PR)
Restored
15 (commented on own PR)
Forgot to mention, I changed the sorting order to be compulsory for easier implementation
16 (commented on own PR)
actually %1$s is replaced by the string "asc" or "desc"
17 (commented on own PR)
Ok
18 (commented on own PR)
The test for SortAppointmentCommand is not done yet. The current content is simply copied from another file
19 (commented on own PR)
Yes, so do not merge until I finish the rest
20 (commented on own PR)
Should be able to merge now. Finished adding tests
21 (commented on own PR)
The method actually sorts the appointment list but the displayed filtered appointment list is sorted accordingly. Should I change back the javadoc comment?
22 (commented on own PR)
updated
23 (commented on own PR)
Fixed. Thanks!
24 (commented on own PR)
Fixed
25 (commented on own PR)
Actually, in AppointmentBook::resetData, only the appointmentList gets replaced
26 (commented on own PR)
I have added getCommandWord(String) in PocketEstateParser
27 (commented on own PR)
can
28 (commented on own PR)
fixed
29 (commented on own PR)
Thanks for your kind suggestion.
30 (other comment)
Sure!
31 (other comment)
Only supports undo for add, delete, edit commands. Tests will be added later.
@simran-bhadani3 (4 comments)1 (commented on others PR)
Something seems missing here?
2 (commented on others PR)
Very minor suggestion but you can consider renaming the method to updateDeliveryStatusToDelivered just to make the name more descriptive.
3 (commented on others PR)
Remember to add Javadoc comments for this method and also the other public methods,
4 (commented on others PR)
There seems to be a stray Javadoc comment here.
5 (commented on own PR)
I followed the same convention as the Person model where they use value to store the value of the object.
6 (commented on own PR)
Oh yeah good point about the parser! I will edit the regex accordingly.
I think the regex in the Name class does not accept single characters.
7 (commented on own PR)
oh yes didn't think about that! Will update it accordingly!
8 (commented on own PR)
I am not really sure whether there are any use cases for equals. Probably will leave it in for now in case it is needed and remove it later if it is not used.
9 (commented on own PR)
oh yeah that's a good point, will do that
10 (other comment)
Fix #12
11 (other comment)
Fix #5
12 (other comment)
Fix #14
13 (other comment)
Apart from the replacement of person by order as already mentioned by @xiinweii98, LGTM as of now.
14 (other comment)
Fix #78
@mechastriker3 (4 comments)1 (commented on others PR)
yea i think can
2 (commented on others PR)
Are these commented out stuff important?
3 (commented on others PR)
But i think looks ok overall, let's merge it !!!
4 (commented on others PR)
yup, or can we use taggedList?
5 (commented on own PR)
yup agree
6 (commented on own PR)
Ok, we can standardise to use the Option class to represent a option instead of using a string, similar to prefix.
i'll just tag everyone and myself to remind us to use it @edelinetenges @nicoleang09 @Stratostorm @mechastriker3 @clarlzx
7 (commented on own PR)
ok
8 (commented on own PR)
that makes sense
9 (other comment)
test reopening issues
10 (other comment)
Looks good
11 (other comment)
this PR is voided
12 (other comment)
closes #41
@nicoleang09 (4 comments)1 (commented on others PR)
Perhaps this line can be broken down for better readability?
2 (commented on others PR)
Maybe this can be phrased as "clears all entries from the address book if tags are not specified..."
3 (commented on others PR)
Should "the option" be capitalised?
4 (commented on others PR)
Should this example be changed to match the usage
5 (commented on own PR)
I was thinking about that too, but when they used step 1, step 2... it was to describe the actions a user performs. Mine is more of the sequence of how the code handles the scenario, so I was not sure if it will be confusing if I use the same convention.
6 (other comment)
addAppt implemented when setting up appointment logic.
7 (other comment)
Resolved by #132
@goatygoatygoat (4 comments)1 (commented on others PR)
I think you must make a new class called EntryTagContainsPredicate which implements Predicate>Entry> and do your implementation for filtering tags there, then pass an instance of that class as a parameter into the updateFilteredEntryList method. The ListEntryFormatPredicate is used for listing entries only.
2 (commented on others PR)
This class can be deleted.
3 (commented on others PR)
This class can also be deleted.
4 (commented on others PR)
Change to contact
@Shuyang0 (4 comments)1 (commented on others PR)
I like how you explained the implementation of Schedule.
2 (commented on others PR)
Looks good.
3 (commented on others PR)
Looks good.
4 (commented on others PR)
Looks good.
@awzhenyi (3 comments)1 (commented on others PR)
there is a large chunk of spaces(?) here, not sure if it is intended
2 (commented on others PR)
There is a space here, not sure if it is intended?
3 (commented on others PR)
is this sout suppossed to be here?
4 (commented on own PR)
Thanks, done!
@car155 (3 comments)1 (commented on others PR)
I think need to abstract the method here. You can move the null checks to the assignment class and assignment command parser to comply with the other model objects/methods. Since the Model and model manager are mostly facades.
2 (commented on others PR)
This method i think can be abstracted too. Can call a method in person which calls a method in the session list.
3 (commented on others PR)
Should we allow multiple student assignments at the same time? Like in tags
@Winniehyx (3 comments)1 (commented on others PR)
is this a typo?
2 (commented on others PR)
mechanism*
3 (commented on others PR)
should it be feature instead of mechanism?
4 (commented on own PR)
Yup sorry slipped my mind our project name changed.
5 (commented on own PR)
yup sorry for the typo!
6 (commented on own PR)
Yup! i will change it.
7 (other comment)
LG
8 (other comment)
TM
9 (other comment)
Need to fix checkstyle error
10 (other comment)
lgtm
@Donavanty (3 comments)1 (commented on others PR)
Good explanation. I was thinking if we could add a line mentioning that this would be more most apt for situations where the review could be too long => using the view feature shows more of the review.
2 (commented on others PR)
Line 39: ... e.g. the review element may contain a long review that is shortened in the main window; using view will be apt for the user to view the whole review.
3 (commented on others PR)
Good addition 😃
4 (commented on own PR)
Will change to 'entry', thanks 😃
5 (commented on own PR)
This is now 130.0 (instead of 100), to accommodate for 4 lines of comments shown without scrolling
6 (commented on own PR)
I did styling on TextArea individually instead of using DarkTheme.css, might have to change in the future if colour scheme changes
7 (commented on own PR)
Added Food Categories and School Locations enumeration types in the Help guide, to allow users to see what types they can use
8 (commented on own PR)
Thanks Marcus, yeah probably merged wrongly
9 (commented on own PR)
Okay, will edit and push again, thanks Sid
10 (other comment)
Centralised Ui image in Readme
11 (other comment)
Internal: Change codes to fit The Food Diary (ie. no "Persons")
12 (other comment)
I'll fix the checkstyles
13 (other comment)
I accidentally merged Marcus' work-in-progress, which is causing checkstyleTest test to fail, but I can't resolve it yet
I'll wait for Marcus to finish the 'edit' function first, then resolve it.
Meanwhile, the HelpWindow is done.
Resolved, used hard reset
@godjuansan (3 comments)1 (commented on others PR)
We copy this from the original implementation of AddressBook
2 (commented on others PR)
Agree, to be consistent with the other prefixes in the CliSyntax.java, I think w/, h/ and mc/ is better
3 (commented on others PR)
ListCommandCommand? How about ListOfCommandsCommand?
4 (commented on own PR)
I have moved it inside the command itself
5 (other comment)
merged already
@OhJunMing (3 comments)1 (commented on others PR)
Side note, I notice we didn't really use Tag attribute from AB3.
Any ideas to use it or just leave it
2 (commented on others PR)
maybe more user friendly to change to "dob/ " instead of b/
3 (commented on others PR)
I assume this works on the GUI
Not really proficient on fx language haha
4 (commented on own PR)
Hey,
yup yup, my mistake
Already amended it.
Can check it again:)
5 (commented on own PR)
hey, I just changed to Car@leads psps
6 (commented on own PR)
Hey im not really sure abt "hash code account"
I amend to return this.hashcode;
this refers to the car object
7 (commented on own PR)
agreed, changed to Car(String carBrand, String carType)
8 (commented on own PR)
Yea, should e no issue, very very minor edit of the naming of the java doc commetns, not like adding test code
9 (commented on own PR)
LOL, this caused recursion, stack overflow, but I corrected it, its works now
10 (other comment)
I don't think this can be merged.
the photo needs to be your name and show ur face, in low resolution at least, according to the week 7 website requirements
I have already helped to change the about us and added ur image in the pull request aboutus/shizheng
11 (other comment)
Yup looks good, so we start afresh with the UG and DG
12 (other comment)
@rajobasu
I will close this, I presume your week 6 tutorial task has been fulfilled.
Don't want to clutter the open pull requests:)
13 (other comment)
@rajobasu
I will close this, I presume your week 6 tutorial task has been fulfilled.
Don't want to clutter the open pull requests:)
14 (other comment)
DONT MERGE YET, STILL TESTING
15 (other comment)
WE ARE DONE ! address is back in!
16 (other comment)
WAIT LET ME REFACTOR
AFTER I MERGED SHERMAN PR, there were some conflicts, unintended behaviours
@RuiXiong2211 (3 comments)1 (commented on others PR)
This can be shortened to just this.zeroBasedIndex - index.zeroBasedIndex. (I think)
2 (commented on others PR)
While it may already be intuitive, maybe you can add a comment that the function sorts the dates according to the earliest to the latest.
3 (commented on others PR)
I am not too sure what the variable value means here.
4 (commented on own PR)
fixed
5 (commented on own PR)
fixed
6 (commented on own PR)
yep, changed the conditions to be more strict.
7 (commented on own PR)
oops, meant to be RemindCommand
8 (commented on own PR)
changed
9 (commented on own PR)
Looks great!!
Also, wanted to ask whether inputting an add/find command after a remind command changes the address book back to the original person list? Not sure if the addressbook already takes care of that somewhere else.
@pavz02 , RemindCommand acts on a different list than add command, but on the same "filtered" order list as FindCommand, it will not affect the state of the original person list.
10 (commented on own PR)
it should be initialized as an empty string, thanks for catching that, i forgot to test the addcommand
11 (commented on own PR)
changed
12 (commented on own PR)
added more requests
13 (commented on own PR)
i was wondering why the ab3 tutorial added a prefix too, i think its used to mark the start of the request, but im not too sure why they added it in the first place, so i left it as it is.
14 (commented on own PR)
yep, for now it looks like the tag and undelivered tag, wanted to make it stand out more.
15 (commented on own PR)
changed
16 (other comment)
LGTM
17 (other comment)
LGTM
18 (other comment)
LGTM
19 (other comment)
LGTM
20 (other comment)
LGTM
21 (other comment)
LGTM, maybe you can update the user guide as well to reflect the changes that have been made.
22 (other comment)
LGTM, will be merging this to the master branch so that I can fix some merge conflicts on my end.
23 (other comment)
Fix #85
24 (other comment)
Skimmed through it and left some comments you might want to consider. Other than that, LGTM 👍
edit: also I'm guessing you're not planning to add requests using the Add command?
I am still unsure of how an order requires a request but the request is not added with the add command. I thought you would be implementing it with the add command as an optional field (optional like the tags), so if I misunderstood your implementation sorry haha
It is implemented with a separate command, but now that i think about it i should have probably implemented it with the add command lol i thought it would be neater to use a separate command to add requests instead of overloading the addcommand. In my implementation, requests are initialized to be empty at first and added with a separate command.
25 (other comment)
LGTM
26 (other comment)
Fix #93
27 (other comment)
The files you've edited look good. Can I check if the json file created as expected in your data directory? If so LGTM 😃
Yep, there's a json file created in the data directory, the json file currently contains the SampleDataUtil OrderItems Model's data.
@jellymias (3 comments)1 (commented on others PR)
I believe that Model actually has a hasEvent(int index) method that can be used here instead!
2 (commented on others PR)
Is there a need to change the boolean form here?
3 (commented on others PR)
Very clear documentation!
4 (commented on own PR)
thanks for pointing that out!
5 (commented on own PR)
Ah thats a good idea!
6 (commented on own PR)
thanks!
7 (commented on own PR)
yes marcus pointed it out too. I fixed it alr!
8 (commented on own PR)
hmm the null is okay because we check again in EditAssignmentCommand.java
9 (other comment)
i can do the event skeleton, add and edit
@LimJunxue (3 comments)1 (commented on others PR)
Can change the system from addressbook to planit?
2 (commented on others PR)
Should this be start time?
3 (commented on others PR)
Using {:toc} allows us to see all the headers so is that better?
4 (commented on own PR)
Alright thanks!
5 (commented on own PR)
It is in ongoing works.
6 (commented on own PR)
It is in ongoing works.
@arsatis (3 comments)1 (commented on others PR)
Very detailed and well-written! Looks very comprehensive 👍
2 (commented on others PR)
Good that you have edited this part out!
3 (commented on others PR)
Documentation for this method looks great!
4 (other comment)
LGTM 👍
5 (other comment)
LGTM!
6 (other comment)
lgtm
7 (other comment)
lgtm
8 (other comment)
lgtm
9 (other comment)
lgtm
10 (other comment)
lgtm
11 (other comment)
lgtm
12 (other comment)
lgtm
13 (other comment)
lgtm
14 (other comment)
Good job adding the methods required for borrowing books to readers! Maybe we might want to consider separating/abstracting the methods related to borrowing/returning books in the SmartLib class to a separate class?
15 (other comment)
There were some bugs with my local tp file, this pull request is just to check whether my local tp file has been successfully debugged.
16 (other comment)
Will merge this first, so that the others who are trying to update the developer guide will not have to perform these edits again.
17 (other comment)
This pull request looks good to be merged into our group's repository!
18 (other comment)
This pull request looks good to be merged into our group's repository!
19 (other comment)
This pull request looks good to be merged into our group's repository!
20 (other comment)
This pull request looks good to be merged into our group's repository!
21 (other comment)
This pull request looks good to be merged into our team's repository! 👍
22 (other comment)
This commit looks good to be merged!
@rajobasu (3 comments)1 (commented on others PR)
Hey can you remove the role part, since for now I think we are randomly distributing tasks so that we all get to learn equally? We discussed this yesterday i guess. otherwise LGTM!
2 (commented on others PR)
Hey, I actually changed the names from Car@Tinder to Car@leads as you told yesterday, can you reflect these changes?
3 (commented on others PR)
LGTM
4 (other comment)
@nighoggDatatype Need to merge the conflicts! After that will accept
5 (other comment)
Yep, LGTM
@colintkn (2 comments)1 (commented on others PR)
UserGuide still seems to reflect "iclose INDEX"? Maybe userguide can be edited to reflect the change
2 (commented on others PR)
I didn't know how to use multiple tags at first. Can consider putting command example for both:
'iadd r/10-100 d/Broken light c/Furniture g/ HIGH
'iadd r/10-100 d/Broken light c/Furniture g/ HIGH g/ URGENT
3 (commented on own PR)
Yes, its optional. I showed two variations in the use examples. But I'll explicitly put that r/ is optional under the radd explanation
4 (commented on own PR)
removed this chunk of code. Thank for pointing out.
5 (commented on own PR)
Noted. Added actions to represent the checks. And used guard clauses.
6 (commented on own PR)
Ok. Added the example command to the userGuide.
7 (commented on own PR)
Added this point. Thank you.
8 (commented on own PR)
Good point raised. Will make the changes.
@ampan98 (2 comments)1 (commented on others PR)
Perhaps the command format could be simplified to massdelete s/INDEX e/INDEX instead of having to type out the full words for start and end?
2 (commented on others PR)
I feel that the exclamation marks are unnecessary and do not fit the style of the app responses. Is there a reason for them?
@Shizheng001 (2 comments)1 (commented on others PR)
ok
2 (commented on others PR)
will update to delete customer base on name
@Assyarul (2 comments)1 (commented on others PR)
If we were to set Person as immutable, setDates, setMeetings and setPicture might need to shift to a different class instead. Maybe a PersonFactory?
Either this or state in comments there are mutable fields present in Person.
2 (commented on others PR)
Add javadocs comment here.
3 (commented on own PR)
Sounds good. Added the glossary back in.
4 (commented on own PR)
Fixed
5 (commented on own PR)
Test cases seems to make it hard for you to pass in a LocalDate as an argument. I changed the validation to use #41 dateUtil. Should we still make it as a LocalDate field?
6 (commented on own PR)
The rest of the other 'with' methods doesn't do their parsing in this testutil though. I think what I'm going to do is,
Allow birthday to accept a string and parse the string. This is primarily for testing.
Create an overloaded constructor which directly accepts a LocalDate. This is what the app will be using.
7 (commented on own PR)
Tried using stream but parseIndex throws an exception. Apparently unhandled exception does poorly with streams unless I explicitly throw it inside the lambda.
8 (commented on own PR)
add-debt and subtract-debt both have almost the exact same implementation in terms of both commands and parsers. Implementing them separately seems inefficient. Implementing them via the ChangeDebtParser and ChangeDebtCommand and passing a boolean increases code reusability.
I feel that adding in an extra boolean input worth it comparing to the additional bloat that will be added in creating more separate commands and parsers.
9 (commented on own PR)
Command only accepts positive value, hence the need for add-debt and subtract-debt.
10 (commented on own PR)
The debt class is to store debt within a Person. We can have negative debt to indicate the person owing money to the user instead.
The ParserUtil.parseDebt is used to parse debt passed into the ChangeDebtCommand, while Debt.isValidDebt is used to validate Debt. I will change parseDebt to parsePositiveDebt for clarity.
The reason for implementing this way is that the user would normally change the debt amount indirectly through adding/subtracting unlike the other fields that would be edited directly using edit.
Hence the Parser requires a different method to parse positive debt amount rather than the default valid debt.
11 (commented on own PR)
Removing the conditional would introduce even more code by duplicating the behaviour here again in another command.
12 (commented on own PR)
Will implement toUi() in Debt.
13 (commented on own PR)
See above.
14 (commented on own PR)
Sounds like a good idea here.
@Stratostorm (2 comments)1 (commented on others PR)
Whats all this stuff? Can just delete?
2 (commented on others PR)
Somemore leftover comments here
3 (commented on own PR)
Yep, thats a typo
4 (other comment)
resolved by PR #22
5 (other comment)
Add instructions to the UserGuide to teach the user how you can export your contact list to another device running Helibook by copying the data file.
6 (other comment)
Decided that this issue is no longer in line with project direction
@SiTingST (2 comments)1 (commented on others PR)
It seems more appropriate to change it to StudentBook.
2 (commented on others PR)
Perhaps you can consider placing a quotation for the command, for i.e. 'Add Student' to enhance readability?
3 (commented on own PR)
We should use the StudentBook::isExistingMatricNumber method and boolean is sufficient. Thanks for pointing this out!
4 (commented on own PR)
Since date and startTime are supposed to be of type LocalDate and LocalTime respectively, it would be a better idea to just store them as their own type instead of String.
5 (other comment)
resolve #113
6 (other comment)
Would be good to include more assertions
@tashawan23 (2 comments)1 (commented on others PR)
AddressBook has been changed to HeyMatez
2 (commented on others PR)
Just need to change these names to HeyMatez
3 (commented on own PR)
This is for the editTask command to be added later so that the user can specify which attribute of the task to edit
4 (commented on own PR)
I thought it was simpler to follow what was already implemented so that it is easier to check whether the description is valid too
5 (other comment)
Implemented and merged
6 (other comment)
Implemented and merged
7 (other comment)
Merge add deadline
@yienyoong (2 comments)1 (commented on others PR)
You may want to consider removing these extra blank comment lines 😃
2 (commented on others PR)
Nice use of assertions!
@cheeerynne (2 comments)1 (commented on others PR)
same like before, would it be better to put expectedModel as a class variable?
2 (commented on others PR)
For expectedModel, would it be better to declare it as a class instance variable instead?
3 (commented on own PR)
Yes, you are right!
4 (commented on own PR)
Sure
5 (commented on own PR)
Ok!
6 (commented on own PR)
Ok sure!
7 (commented on own PR)
Ok!
8 (commented on own PR)
Ok sure!
9 (commented on own PR)
Sure!
10 (other comment)
lgtm
@tsh22 (2 comments)1 (commented on others PR)
Perhaps this 'Implementation' section can be shifted up so that it's in a new section rather than under 'Appendix: Requirements'?
2 (commented on others PR)
There's the option to just use elist without the parameters also right? Perhaps can update the message here
3 (commented on own PR)
Sure sounds good
4 (other comment)
Checks not going through
@mabel-kang (2 comments)1 (commented on others PR)
Perhaps this should be changed to one that fits the ScheduleCommand class
2 (commented on others PR)
Perhaps this should be changed to one that fits the ScheduleCommand class
@maikongeh (2 comments)1 (commented on others PR)
Looks good to me. SLAP is adhered to and method is not too long or overly nested
2 (commented on others PR)
is RemindedParser a typo?
3 (other comment)
I can do general event done and delete
GE attributes, String description, LocalDateTime
general event description prefix - g/
general event LDT prefix - on/
4 (other comment)
looks good. Follows the same format as the other edit commands and parsers
@xinweit (2 comments)1 (commented on others PR)
The GUI similar to the picture below
2 (commented on others PR)
lgtm. just want to clarify the JSONArray jsonTags passed as a parameter here is a json array of all of the 'tagged' field values in our database flashcards.json?
3 (commented on own PR)
I think so too. However only the modelmanager is passed into execute and since the mode resides in modelmanager I cant find a way to abstract it out
4 (commented on own PR)
good idea, implemented
5 (commented on own PR)
added to gitignore in new PR
6 (other comment)
Added greetings message for the app.
7 (other comment)
Figured out logic behind GUI display
8 (other comment)
Added greetings message for the app.
Perhaps create a PR for it, as it will probably be something useful for the application? 😃
Sure yucheng, created the PR
9 (other comment)
@xinweit after I merged my previous PR into the code base there seems to be a conflict. The conflict is in
MainWindow.javaand it seems its relatively simple to resolve from your side. Its a bit troublesome from my side as I would need to make changes of your PR locally, so can help?
You can resolve it by trying to pull the latest master branch to your GUI-display branch. Thx!! 😃
Sure bro ill do that, no prob
10 (other comment)
updated
11 (other comment)
right now to change the mode of display we are hiding and showing the flashcard panel using setVisibility(boolean) method of javaFX. but I think this mode class will come into handy next time when we want to say parse different commands based on the current type of mode (quiz or learn), ie. commands specific to quiz or learn mode
12 (other comment)
nice. lgtm
13 (other comment)
Should only be able to start when user is in quiz mode I think. Working on it.
14 (other comment)
Err so this PR is a super set of your PR 74 and 76? Sorry I am a bit confused
Yeah it includes those as well.
15 (other comment)
Will be closing this pull request due to a problem in pushing to this quiz-duration branch.
16 (other comment)
Feature, not a bug
@aaronsms (1 comments)1 (commented on others PR)
Should be fine I guess.
2 (commented on own PR)
Okay will specify that it is getter for the fields. But this is still necessary because we want to keep it hidden from the rest of the classes.
3 (commented on own PR)
But note that these changes are essential for us to have the objects be testable. Or else, you can't instantiate a ID with some particular fields without changing the underlying counter. Previously, unlike CustomerId; OrderId and CheeseId are instantiated with native constructor, with no way of not incrementing the underlying counter.
4 (commented on own PR)
By the way, the comment was carried over from seedu.
5 (commented on own PR)
Yeap this is updated.
6 (commented on own PR)
Yeap this is updated in the latest push.
7 (commented on own PR)
Hmm this one we do allow to edit tags, so this would be okay.
8 (other comment)
2F + Mockup - Wei Xue
2F + DG - Lauren
2F + UG - Li Quan
2F + README - Aaron
3F - Daniel
9 (other comment)
@daniellau88 it's your call, the workflow build fails because it tries to access the secrets from the master repository. Other than the access issues, it should be working.
10 (other comment)
Yeap seems like I have included the wrong token. I have updated the secret with the chat ID of our Telegram group.
11 (other comment)
Actually do you want to squash some of your commits, before merging. But other than that, everything seems fine.
12 (other comment)
Now the issue is the workflow works for push events, but not from the pr from forked, because GitHub doesn't expose secrets to forked-triggered workflows. Seems like we have to close this one down, as our current workflow, we are not pushing/pr-ing from master repository's branches, the notifier doesn't work in this case.
13 (other comment)
Since this will not work for our current workflow, unless using plain text tokens, I will close this down. Maybe use it for v1.3.
14 (other comment)
I will recommend squashing your commits before merging if possible.
15 (other comment)
There is one class of ModelStub with no useful methods, and the rest of variations are extending from it and overiding methods important for testing. We could make it abstract though. What else do you think we can do. The idea is we have two kind of test suites: 1 with using the actual ModelManager and 1 using just the stubs.
16 (other comment)
Fixed the above mentioned issues but also, the Json parsing to model for cheese is also not fixed with parsing null fields, and thus have some initialization issues. Have fixed all.
@ljhgab (1 comments)1 (commented on others PR)
Maybe can change the parseTags here to a parseCategories? 🤔
2 (commented on own PR)
Ok thanks!
3 (commented on own PR)
Maybe i will hand over this part to you haha.
4 (other comment)
I haven't inspect on that deeper so I am not quite sure 🤔
5 (other comment)
LGTM
@vvan-essa (1 comments)1 (commented on others PR)
Nice catch!! 👍
2 (other comment)
LGTM!
3 (other comment)
im so sorry i clicked the wrong link!! thank you!!
@Sidney011100 (1 comments)1 (commented on others PR)
java version should be less than or equal to 11
2 (other comment)
Done with the merging of ui-for-school-tags
@internityz (1 comments)1 (commented on others PR)
would this cause a problem where name will be searched when user searched for a student's school
@banchiang (1 comments)1 (commented on others PR)
execute method looks good but might want to do abit more abstractions to make the method LOC to be less than 30!
@Jonathan-Cao (1 comments)1 (commented on others PR)
Detailed documentation
2 (other comment)
Now we have to integrate Type into matching as well.
3 (other comment)
Detailed explanation. Good job!
@SoonKeatNeo (1 comments)1 (commented on others PR)
Thanks for styling the diet plans nicely! +1.
2 (other comment)
PR contributes to #18
3 (other comment)
This PR contributes to #16.
4 (other comment)
This PR contributes to #16.
5 (other comment)
This PR contributes to #16.
6 (other comment)
Contributes to #18 .
7 (other comment)
Contributes to #18 .
8 (other comment)
#18
9 (other comment)
Closing, all updated.
@Sharptail (1 comments)1 (commented on others PR)
Is this printing intentional? If it is, should use logging instead 😃
2 (other comment)
Looks good to merge
3 (other comment)
Reopen to link PR
4 (other comment)
Looks good to merge to fixes #9
5 (other comment)
Reopen to remove traces of AB-3
6 (other comment)
Reopen to remove traces of AB-3
7 (other comment)
Reopen to remove traces of AB-3
8 (other comment)
Reopen to remove traces of AB-3
9 (other comment)
Reopen to remove traces of AB-3
10 (other comment)
fixes #9 as well
11 (other comment)
Fixed by #28
12 (other comment)
Fixed by #23
13 (other comment)
Closing this issue because is fixed with #53
14 (other comment)
Closing this issue because is fixed with #53
15 (other comment)
Closing this issue because is fixed with #53
16 (other comment)
Closing this issue because is fixed with #48
17 (other comment)
Closing this issue because is fixed with #48
18 (other comment)
Closing this issue because is fixed with #48
19 (other comment)
Closing this issue because is fixed with #48
20 (other comment)
closed for potential feature
@jamesleeht (1 comments)1 (commented on others PR)
Variable naming convention
2 (other comment)
LGTM!
3 (other comment)
LGTM
@Marc-97 (1 comments)1 (commented on others PR)
Should the link be from our repo instead?
@ssoonwee (1 comments)1 (commented on others PR)
I feel the command should be rephrased to foodintakeupdate for consistency with the rest
2 (other comment)
LGTM with more detailed descriptions.
3 (other comment)
lgtm.
4 (other comment)
looks good!
@deyixtan (1 comments)1 (commented on others PR)
@eksinyue I think you can use the logger instance to print out your debug messages.
2 (other comment)
@jxrrelo Got it, let me take a look!
3 (other comment)
@eksinyue Is this the same as #115?
4 (other comment)
@eksinyue Hmm, the exceptions can be seen in the console logs ahaha
5 (other comment)
@eksinyue I tried to apply the changes on my side and I'm still getting those exceptions 😮
6 (other comment)
@eksinyue
Hmm I think the root of the issue stems from your addFinancialRecord in BudgetBabyModelManager. The condition always return false.
Maybe you can try this and see if the issue still persist?
@jasaaanlim (1 comments)1 (commented on others PR)
Perhaps the magic numbers can be replaced with named constants to make the formula easier to understand 😃
2 (commented on own PR)
Good point! Will update this.
3 (commented on own PR)
Updated command name.
4 (commented on own PR)
You are right! Thanks for pointing that out!
5 (other comment)
Looks good to merge!
6 (other comment)
Looks good to merge.
7 (other comment)
LGTM
8 (other comment)
#90
9 (other comment)
LGTM!
@linhns (1 comments)1 (commented on others PR)
I think can just leave it in the old form as ParserUtil is static but looks fine
2 (commented on own PR)
I changed the checkstyle to allow wildcard imports since we import considerably from one package. Wildcard imports should be ok if you import more than 3 functions/constants from a package
3 (other comment)
LGTM
4 (other comment)
Nice job. Will merge when everyone has updated UG and DG
@vivegank (1 comments)1 (commented on others PR)
Another one
2 (other comment)
Just to have a user story to close after we finish adding stuff for v1.2
@khiaxeng (1 comments)1 (commented on others PR)
Just to confirm, is System.out.println() supposed to be there?
2 (commented on own PR)
Done, added a test case for invalid args
3 (other comment)
LGTM *
4 (other comment)
PR has been merged already.
5 (other comment)
Decided not to remove any fields in Person.
6 (other comment)
If add command does not specify date, default the date to 'today'
7 (other comment)
Show all tasks with one specified deadline (in 2nd column)
8 (other comment)
Show Tasks based on State
9 (other comment)
Example: 'delete completed' will delete all completed Tasks
10 (other comment)
Did you mean to link issue #81 ?
@yuheem (1 comments)1 (commented on others PR)
Indentation for wrapped lines should be 8 spaces according to CS2103T's coding standard. Not a major issue.
@Jellybeano (1 comments)1 (commented on others PR)
not too important but probably can import the static final variable MODE_QUIZ and MODE_LEARN so that the code looks nicer? 😄 same for the rest of the magic numbers
2 (commented on own PR)
Fixed!
3 (commented on own PR)
Oh thanks for catching that haha
4 (commented on own PR)
gots it
5 (commented on own PR)
new commit for added abstraction as well as clearer names for the image variables
6 (other comment)
Solved in #60
7 (other comment)
Solved in #86
8 (other comment)
Solved in #86
9 (other comment)
Solved in #93
10 (other comment)
Solved in #88
@ZhangAnli (1 comments)1 (commented on others PR)
Could you use the [] brackets instead of the >> brackets as per the format above
2 (commented on own PR)
Edited
3 (commented on own PR)
Edited
4 (commented on own PR)
Edited
5 (commented on own PR)
Edited
6 (commented on own PR)
Edited
7 (commented on own PR)
Edited
8 (commented on own PR)
Edited
9 (commented on own PR)
Edited
10 (commented on own PR)
Edited
11 (commented on own PR)
I think for this I didn't use the asObservableList method
12 (commented on own PR)
Removed
13 (commented on own PR)
Edited
14 (commented on own PR)
Edited.
15 (commented on own PR)
Edited.
16 (commented on own PR)
Edited.
17 (commented on own PR)
Edited.
18 (other comment)
No longer relevant.
19 (other comment)
Refactor UniqueEntityList to remove unnecessary methods that use Entity parameters.
20 (other comment)
Closes #236.
21 (other comment)
Minimum requirement: ready for Saturday dry run.
@BigDoot (1 comments)1 (commented on others PR)
Typo on this line
2 (other comment)
Done
@jxrrelo (1 comments)1 (commented on others PR)
Both the BudgetDisplay() and updateObservableList() methods appear to have a number of lines of repeated code which violates the DRY principle. You could perhaps refactor your code to patch this up 😃
2 (other comment)
implement find-fr command
@JerardSoh (1 comments)1 (commented on others PR)
Should it be showEvent( instead?
@sjq-sohjunqi (1 comments)1 (commented on others PR)
Would it be better if the regular expression was defined as a final variable instead?
2 (commented on own PR)
I see! Thanks for the suggestion!
3 (other comment)
There are issues when calling progress while no active diet plan is selected as well as printing the total adherence to plan
@justgnohUG (1 comments)1 (commented on others PR)
The one in address/logic/commands is an {abstract} class and exists in a different package from this Command.java.
I think since they are clearly differentiable by file path, it shouldn't be an issue. Because alias/Command.java is named as such logically.
"Paths (or URLs) are nice because they are nested identifiers."
2 (commented on own PR)
Made changes to the statement
3 (commented on own PR)
Fixed and removed.
4 (commented on own PR)
This test was originally to ensure the commands are sorted. Under the assumption the "add" command will always be present, regardless, the first command at index 0 should always start with a.
Perhaps a suggestion is to test every first letter of each command and see if they are alphabetical?
5 (commented on own PR)
Modified test case following 1.
Decided to compare element by element.
Thank you for the suggestion.
6 (commented on own PR)
I get your drift.
It was my mistake to include the Collections.sort() again right after calling the method. It is already called in getAutocompleteCommand().
I have implemented your suggestion 2 as per your previous comment. I am using the comparator method so the hard-coding of commands is minimized.
7 (commented on own PR)
Thank you for the spot.
I've added a test case to handle Empty spaces / white spaces.
Documentation for the method getAutocompleteCommands has been added.
8 (commented on own PR)
Fixed! Thanks
9 (commented on own PR)
Fixed!
10 (commented on own PR)
I believe it was accidentally added
11 (other comment)
LGTM
12 (other comment)
LGTM
13 (other comment)
@yaowei-soc fixed PR naming convention to provide more context and information.
Thanks for the reference.
14 (other comment)
Bug found, commands do not show up on start-up sometimes.
15 (other comment)
Nice. Thanks for enabling assertions.
16 (other comment)
Works for me.
17 (other comment)
LGTM.
@eksinyue (1 comments)1 (commented on others PR)
Just a thought, is it a good idea to return past month's statistics as a String? Maybe it would be a better idea to return as a List or HashMap? That way, it will be easier to format and display on the Ui side.
2 (commented on own PR)
Good catch. Thanks!!
3 (commented on own PR)
Thanks for pointing it out. I forgot to remove it before pushing.
4 (other comment)
Is this similar to issue #74 ?
5 (other comment)
@eksinyue I don't think it will fully resolve #73. If I'm not wrong, after adding/deleting a financial record, the budget will still retain at its original displayed value. But apart from that, I think LGTM!
oh okay!! Sorry I misunderstood issue #73. I will merge this PR first without closing the issue.
6 (other comment)
@deyixtan I followed the instructions and did not get the IndexOutOfBoundsException.
Here is a screenshot of the app after the last delete-fr 2 command
@andrea-twl (1 comments)1 (commented on others PR)
Probably need to change this class name eventually to accommodate searching by tag
@hengyiqun (0 comments)1 (other comment)
@totoyoyo
Rectified
2 (other comment)
LGTM
@geraldfan (0 comments)1 (other comment)
As a busy CS student, I want to know which deadlines are coming up, so I can focus on them first.
As a CS student who has weekly quizzes, I can be alerted when the deadline of the quiz is coming up, so that I don't miss any quiz.
As a CS student, I can check my module deadlines and information at the same location, so that I don't have to navigate between multiple tabs.
As a CS student, I can set notes for the tasks, to record information about the task.
As a CS student, I can break a task down into several smaller tasks to better organize my tasks
As a CS student, I can view my schedule in calendar format to better plan my time.
As a first-time user, I can view a help message explaining the features so that I can orientate myself with the app
As a CS student, I can delete tasks that I no longer need to track.
@totoyoyo (0 comments)1 (other comment)
lgtm
2 (other comment)
Done by maurice.
3 (other comment)
Lgtm
4 (other comment)
Go to 1.3
5 (other comment)
Completed
6 (other comment)
Added
7 (other comment)
Move to 1.3
8 (other comment)
I'll pull this in since there are no conflicts.
9 (other comment)
LGTM
10 (other comment)
Actually the tests fail
11 (other comment)
Nice fixing of test
12 (other comment)
Should look good to merge.
13 (other comment)
Oh no the tests fail.
14 (other comment)
I fixed the tests.
15 (other comment)
This is done as part of the tP progress.
@icytornado (0 comments)1 (commented on own PR)
yup can create one for the appointment, but the output message would be the same, which is "The patient index provided is invalid"
2 (commented on own PR)
Just created one. Thanks
3 (commented on own PR)
agree, thanks for pointing out
4 (commented on own PR)
updated. Thnanks
5 (commented on own PR)
Hi this method is different from Method Contains.
Method Contains returns return internalList.stream().anylMatch(toCheck::equals);
Method editContains returns ireturn internalList.stream().allMatch(toCheck::equals);
6 (commented on own PR)
i think they are different because the editContains is different from Contains
7 (commented on own PR)
Thank you for pointing out!
Can i keep it for now? because it separates from the functions used by add-appt.
In the future if there will be some changes, i can change it easily without breaking the code for add-appt.
In the finalised version, if they are the same, i will rename them.
It has the flow of : hasEditConflictingAppointment -> hasEditAppointment -> editContains
Otherwise the flow would be: hasConflictingAppointment -> hasAppointment -> editContains.
8 (commented on own PR)
OK. Thanks for pointing out.
9 (commented on own PR)
just changed, yes you are right. And i didnt create field for appointment index
10 (commented on own PR)
you are right. Removed duplicate methods
11 (commented on own PR)
you are right. Thanks for pointing out. I just removed duplicate methods
12 (commented on own PR)
you are right. I removed it
13 (commented on own PR)
thanks for pointing out. changes are completed. Will push again soon
14 (commented on own PR)
Hi, i just added in the index for appointments
15 (commented on own PR)
yes you are right. Changes were made. Thank you
16 (commented on own PR)
you are right.
17 (commented on own PR)
i get what you mean. i try to change
18 (commented on own PR)
yup, have made the changes and pushed again. Thank u
@douglaswja (0 comments)1 (other comment)
done with my commands
2 (other comment)
done w my portion
3 (other comment)
The Ubuntu and Macos CI's seem to be failing due to test cases, so for now we can ignore these.
Not too sure why the Windows CI is failing, could attempt to address test cases first.
4 (other comment)
Hey, you currently have some merge conflicts in your PR, could you update your local master branch and resolve them.
Thanks!
Can let me know if you need help with this.
5 (other comment)
Done with User Stories
6 (other comment)
Need to update the existing bullet points in README.md to include a short summary of our product.
7 (other comment)
INCOMPLETE:
Needs the current semester and master plan functionality.
8 (other comment)
@Yihe-Harry Could you close this issue if grades can now be added.
Feel free to link your relevant PR that solves this issue.
9 (other comment)
The history command does this, dependent on modules being able to be added with a grade.
10 (other comment)
Now able to work via history command.
11 (other comment)
Incomplete PR, just leaving it open.
12 (other comment)
Pls close once everyone has updated their portions of DG.
13 (other comment)
Done
@Maurice2n97 (0 comments)1 (other comment)
LGTM
2 (other comment)
LGTM
3 (other comment)
Attach to issue
4 (other comment)
Closed.
5 (other comment)
Still need to do integration tests of meetings with
-StorageManager
-LogicManager
6 (other comment)
Tests have not been written, will leave to after v1.3 due to time constraints.
7 (other comment)
Possibly text may not be able to display in timetable if meetings are too short.
8 (other comment)
Additionally now the following command works
setTimetable startDate (sets timetable to start at startDate)
setTimetable default to the standard date.
@jaredtengsw (0 comments)1 (other comment)
Redo PR
2 (other comment)
LGTM
3 (other comment)
Made a new PR due to big changes done after this PR
@JQchong (0 comments)1 (commented on own PR)
I added it instinctively.
2 (other comment)
LGTM
3 (other comment)
probably not.
4 (other comment)
I see there are quite a lot of repeated code in here, maybe can try to clean it up?
5 (other comment)
Probably will, though I will still need to see if Ryan has implemented dark mode and light mode, so that conflicts can be avoided
6 (other comment)
Closed due to a better representation of this feature.
7 (other comment)
This issue is resolved when the user interface is being updated.
@IceBear789 (0 comments)1 (commented on own PR)
"e" is already used for email. I'm not sure if I should reuse the same letter for a different function.
2 (other comment)
Are you planning to add support for deletion of nodes in the future?
3 (other comment)
Will you be editing the background colour as well?
4 (other comment)
How will the change be reflected in the UI?
@zoeykobe (0 comments)1 (other comment)
Well done!
2 (other comment)
LGTM
3 (other comment)
Well done!
@xuanqi966 (0 comments)1 (other comment)
Indicate different roles and responsibilities of each member
2 (other comment)
Team lead: Xuanqi
Documentation: Weiming
Testing: Xuanqi
Code Quality: Jiefeng
Deliverables and deadlines: Vanessa
Integration: Jiaying
Scheduling and tracking: Vanessa
3 (other comment)
And automatic saving
@Tomashiwa (0 comments)1 (other comment)
Another teammate has already been assigned this task
2 (other comment)
Note: User may create an instance of Meeting but there is no way to use the instance at this point (eg. cannot add to storage)
3 (other comment)
LGTM
4 (other comment)
Commit names could be improved. Other than that, LGTM.
5 (other comment)
Will be merge first to implement MeetingBookParser.
6 (other comment)
LGTM
@seaniy (0 comments)1 (other comment)
done
2 (other comment)
Everyone's done with individual tasks. Closing issue.
3 (other comment)
done w my portion
4 (other comment)
Done with Use Cases, added 3 use cases. Not sure if need to add more.
5 (other comment)
Completed add/delete plans
6 (other comment)
Need to standardise user guide formatting.
7 (other comment)
Done
@ssagit (0 comments)1 (other comment)
This task is to add/delete plans, semesters and modules as stated in the user guide
2 (other comment)
This is for singular adding of modules (i.e. if I add 3230, I may be reminded that I have not completed CS2040), different from https://github.com/AY2021S2-CS2103-W17-1/tp/issues/17
3 (other comment)
done w my portion
4 (other comment)
done w my portion
5 (other comment)
done w my portion
6 (other comment)
CI matters resolved, matters to note for future CI issues:
Always clear checkstyle before pull requests
Ensure files use LF for line breaks instead of CLRF
Ensure there is a single line break at EOF
7 (other comment)
Test PR used with Week 7 Tutorial
8 (other comment)
Test PR used with Week 7 Tutorial
9 (other comment)
duplicate issue
10 (other comment)
This issue is closed with the current semester command, which is already completed.
11 (other comment)
This is already done with 1.2, with info command.
12 (other comment)
Completed with #102
13 (other comment)
Closed after release.
14 (other comment)
Done
@BenedictBCJJ (0 comments)1 (other comment)
done
2 (other comment)
Done and closed
@austenjs (0 comments)1 (other comment)
As a CS student who does tasks near deadlines, I want to know which task is coming the soonest, so that I can finish it first.
As a CS student who has recurring tasks every period of time (e.g. weekly, monthly, etc), I want to add the task and set a recurring time, so that I don't need to add the same task multiple times.
As a CS student, I want to have notes for each task, so that I remember important information about the task
As a CS student, I want to sort deadlines from each module, so I can estimate how much workload needed for each module
As a CS student, I want to put multiple tasks instantly, so that I don't need to submit multiple times
As a CS student, I want my reminders to show the module code and name
As a CS student, I want to move the reminders easily, so that if the deadline change I can change the reminder easily
As a CS student, I want to know how many deadlines I have and how many deadlines I have done, so I can know whether I am lacking behind or not
As a CS student, I want to have the email of the prof or ta of the module, so that I can contact them if I have an issue with a deadline
As a CS student who just finished a holiday, I want to reset my calendar, so that I can start a new semester with new deadlines
2 (other comment)
wrong issue for current iteration
3 (other comment)
wrong issue for current iteration
4 (other comment)
Yes, i am confused with the additional tasktracker.json. I check the UserPrefs and the default path is to that tasktracker.json instead of /data
5 (other comment)
Removed this feature
@Zaiah0505 (0 comments)1 (other comment)
LGTM!
@jared98lyj (0 comments)1 (commented on own PR)
True haha. Will make the changes.
2 (commented on own PR)
Got it
3 (commented on own PR)
Wah tks you are sharp 😃))
4 (other comment)
Will update EditAppointmentCommand to accommodate both start and end time.
5 (other comment)
Made the appropriate changes.
6 (other comment)
Allowed for modification of timeFrom and TimeTo field in EditAppointment
7 (other comment)
Looks good.
8 (other comment)
Looks good!
9 (other comment)
LGTM
10 (other comment)
Added delete_budget utility
Fixed formatting errors
Updated User guide for budget commands
11 (other comment)
Added view_budget command
Updated user guide
12 (other comment)
LGTM
13 (other comment)
LGTM
14 (other comment)
LGTM
15 (other comment)
Yup forgot to add new methods to one of the test.
16 (other comment)
LGTM. But got some checkstyle issues.
@rjeez (0 comments)1 (other comment)
Fixes #60
Added switch statement to add mode of contact picture beside their descriptions
@NiniJiaying (0 comments)1 (other comment)
LGTM
2 (other comment)
#94
@kwmiw (0 comments)1 (commented on own PR)
Ahh okay, I didn't know about the runtime and checked exceptions part. Will revise it, thanks!
2 (commented on own PR)
Ok! I've gone with both suggestions:
Deleted Regex class to use an enum in TimeslotParser class
Merged both date and time for the non-next commands but of course means there are twice as many enum variables now, but beats creating another enum class just for time.
3 (commented on own PR)
Hmm aites! I changed it to use matcher instead, and to catch exceptions with a boolean isInvalidTime to differentiate the messages likein seb's PR.
But I only created one format with the time -> meaning user has to key in the time and will not be able to leave it empty. Unless I add another conditional for the inputs without time and repeat the matching for dates alone, and create another help method to cut short the matching for date. What do yall prefer!
try {
LocalDateTime currentDateTime = LocalDateTime.now().withSecond(0).withNano(0);
LocalDateTime parsedDate = null;
if (nextDateTimeMatcher.matches()) {
final String nextTimePeriod = nextDateTimeMatcher.group("nextTimePeriod");
final String timeInput = nextDateTimeMatcher.group("timeInput").trim();
// need to repeat matching of dates again, because both are separated and process differently for the next command
if (Arrays.stream(Day.values()).anyMatch(e -> e.name().equals(nextTimePeriod))) {
parsedDate = currentDateTime.with(TemporalAdjusters.next(DayOfWeek.valueOf(nextTimePeriod)));
} else if (nextTimePeriod.contains("MONTH")) {
parsedDate = currentDateTime.plusMonths(1);
} else if (nextTimePeriod.contains("YEAR")) {
parsedDate = currentDateTime.plusYears(1);
} else {
isInvalidTime = true;
}
int[] hoursMinutesArray = parseTime(timeInput);
parsedDate = parsedDate.withHour(hoursMinutesArray[0]);
parsedDate = parsedDate.withMinute(hoursMinutesArray[1]);
parsedDate = parsedDate.withSecond(0).withNano(0);
}
4 (commented on own PR)
hi im facing some issue with this!
currently, if i input without timing:
add-appt pt/5 dr/dr. pluto at/next month dur/1H 30M t/flu t/covid
there will be a NullPointerException and InvocationTargetException (checked). I tried to catch both in the parseNextDateTime and removeMeridian method but no avail... the former says that InvocationTargetException is never thrown too? have yall encountered such an issue before 😊
5 (commented on own PR)
Think EventHandler not working. nt sure if its cux of the commandTextField. trying to use the scene way instead? but can't identify it in the MainApp
6 (commented on own PR)
when I tested this there are no inputs being added to the inputcommand storage zz fixing this too
7 (commented on own PR)
oh got it!
@Juzzanoob (0 comments)1 (other comment)
Closed to allow for new PR to be made without conflicting file.
2 (other comment)
Clarification: CRUD is an acronym for "Create, Read, Update and Delete".
3 (other comment)
LGTM
4 (other comment)
Update EditCommand.java to fix edit bug whereby edit doesn't work if Insurance Plan is the only field of client edited
5 (other comment)
LGTM
6 (other comment)
Code well written and follows proper code principles!
7 (other comment)
Patched with previous PR
@chanellNg (0 comments)1 (other comment)
Added Delete Session Command
Added the relevant classes (deleteSessionCommandParser etc) for the new delete command
updated current test files
Added Ui view for List Persons Command
2 (other comment)
List Sessions Command added
Added Ui view for List Sessions
3 (other comment)
duplicate
4 (other comment)
by checking assigned tutor, assigned timeslot
@Yihe-Harry (0 comments)1 (other comment)
done, ive made the pr
2 (other comment)
Hi i think i resolved the conflict
3 (other comment)
Done
@mrweikiat (0 comments)1 (other comment)
As an SoC student I can filter out non-soc and soc assignments and tasks to improve productivity
As an SoC student i can manage CS coded deadlines by itself since they are not mixed with other faculties mods
As an SoC student I can set reminders for CS coded modules to remind myself of deadlines
As an Soc student i often mix up SoC mods deadlines with other modules, reducing my productivity
As an SoC student, I want to know my CS assignments and deadlines well so i will not confuse with other mods
As an SoC student, I can focus more on my core CS modules by filtering out using the SW
As an SoC Student, I can delete, edit and add CS assignments that are often my core modules. So that I can concentrate better
As an SoC student, I want to finish the CS coded assignments first before other non-CS mods, this SW can consolidate all CS assignments
2 (other comment)
lgtm!
@laurenlhy (0 comments)1 (commented on own PR)
Maybe they can serve as examples of low priority tasks?
@danielonges (0 comments)1 (other comment)
As a CS student, I want to be able to record down all my upcoming deadlines and assignments so that I have a clearer view on how to manage my time effectively.
As a CS student, I would like to sort my deadlines according to the most urgent ones first, so that I can prioritise my work better.
Being a CS students with many other commitments, I would appreciate reminders when I have a CS related deadline approaching, as I might forget some of them due to my busy schedule.
As a CS student that probably has multiple ongoing coding projects, I can tag each project with the language(s) that they are written in, so I know which languages I need to be proficient in
As a CS student, I can tag each assignment with a priority level so that I know where to focus my efforts on.
As a CS student that does work daily, I would like to be able to assign my tasks to a daily to-do list so that I can plan out my day and the work that I need to accomplish for that day.
As a CS student, I would like to be able to make quick notes on the assignments that I have noted down. This could help me get out a quick idea, or leave remarks on certain tasks that might be relevant.
As a CS student, I can mark assignments that I have finished as completed so that it lets me feel a sense of accomplishment.
2 (other comment)
Will resolve merge conflicts later
3 (other comment)
Will merge in my own tutorial since this is my part!
4 (other comment)
Will merge in my own tutorial since this is my part!
5 (other comment)
Will merge in my own tutorial since this is my part!
6 (other comment)
Ok, maybe we can discuss this later? Maybe somebody changed the path accidentally
7 (other comment)
Will fix CI failures
8 (other comment)
Merging to wrong branch
9 (other comment)
Looks like some of the tests weren't refactored from ModuleName to TaskName after the merging with my previous branch
10 (other comment)
lgtm
11 (other comment)
lgtm
12 (other comment)
lgtm!
13 (other comment)
lgtm!
14 (other comment)
CI check failed because of checkstyle
15 (other comment)
lgtm
16 (other comment)
lgtm!
17 (other comment)
Don't know why it merged without even requiring reviews, shall revert and PR again
18 (other comment)
lgtm!
19 (other comment)
lgtm!
@JodyLorah (0 comments)1 (other comment)
looks good 😃
2 (other comment)
Thanks for rmbering abt the CI
~From my iPhone
3 (other comment)
lgtm
@frisciliasultan (0 comments)1 (other comment)
lgtm
@skinnychenpi (0 comments)1 (other comment)
Due to EOF at newline issue, the CI test can't pass.
But the code should function with no error.
2 (other comment)
Finish this task.
3 (other comment)
My checkstyle has some issue, so I can't see where I am wrong in terms of style. Please help me to correct those if you can run the checkstyle, thanks!!!!
4 (other comment)
Simply add the class, further job including integrate it into the model. (Coming up soon)
5 (other comment)
Errors occur because of new methods need to override on the model interface.
6 (other comment)
LGTM!
7 (other comment)
LGTM as well.
8 (other comment)
Looks good!
9 (other comment)
LGTM,
@wangtao0717 (0 comments)1 (commented on own PR)
oh,i don't know when i space here... just delete it
2 (commented on own PR)
it is for checkstyle i think
3 (other comment)
good
4 (other comment)
looks Great
5 (other comment)
Looks Great!
@CSjiade (0 comments)1 (other comment)
Update the index.md file to fit TimeforWheels product
2 (other comment)
Update DoneCommand
DoneCommand "done [index]" will create a checkmark on the entry
3 (other comment)
enable assertion in the gradle file
4 (other comment)
Could try adding test cases for the stats command to ensure it works well
Ok noted will do so asap
5 (other comment)
import * in DeliveryListParser.java preventing the checks from passing
6 (other comment)
Change Syntax of the GUI
@kangtinglee (0 comments)1 (other comment)
LGTM
@IanCKW (0 comments)1 (other comment)
Target user profile, value proposition, user stories, and use cases added. Glossary and NFRs are kept the same
2 (other comment)
LGTM
3 (other comment)
updated Developer guide
4 (other comment)
Added user story in DG. Linked PR for the change
5 (other comment)
all to implement
6 (other comment)
Failed tests. Close
@fairyinabottle4 (0 comments)1 (commented on own PR)
Amended
2 (commented on own PR)
Amended
3 (commented on own PR)
I amended and placed quotations around Add. However I did not place quotations around Student as well because I do not want to give the false impression that that is the correct input format for the Add command.
4 (commented on own PR)
Amended
5 (commented on own PR)
Amended. I also changed the SchoolResidence to be "0..1" to enforce that there can only be 1 SchoolResidence if present.
6 (commented on own PR)
Amended
7 (commented on own PR)
Noted, I'm now using an assertion for defensive purposes instead of throwing an exception
8 (commented on own PR)
Or do you consider this as defensive programming?
Yes, this is defensive.
Does it mean if the Model happens to have an appointment that corresponds to no student, this appointment cannot be edited
Yes
9 (commented on own PR)
Thank you and noted, I have abstracted this in Model in my latest commit.
10 (other comment)
Noted on both, I'll make the changes
11 (other comment)
@picasdan9 I have pushed the changes, I also added the 'x' under AddCommandParser to indicate that it is garbage collected, as you suggested earlier
@nicholasnge (0 comments)1 (other comment)
nice LGTM
2 (other comment)
lgtm, nice \ns
@lrj689 (0 comments)1 (other comment)
Merge this
@kaixiangtay (0 comments)1 (commented on own PR)
This is for list command, list all tasks the user has
2 (commented on own PR)
alright ok just for basic instructions then
3 (commented on own PR)
For now, we will stick to this, it will definitely be applicable and can be extended if required next time.
4 (commented on own PR)
I have fixed my comment to missing year from the starting date.
5 (commented on own PR)
I have fix the correctness of month in starting date
6 (other comment)
I will be refactoring the email field to recurringDate in v1.3 milestone
7 (other comment)
Remember to link the PR to the issue you have been assigned
8 (other comment)
I just help to link the pull request #61 of done command and status attribute to this issue
@WeiLiangLOL (0 comments)1 (commented on own PR)
Ayeee! You're welcome! :DDDDD
2 (other comment)
Merge will close linked issue #54
3 (other comment)
Linked issue #76
4 (other comment)
Closed as mentioned issue proposes fix
5 (other comment)
I would propose using the format below!
{
"foodIntakeLists": [ {
"date" : null,
"foodIntakes" : [ {
"name" : "test",
"fats" : 10.0,
"carbos" : 10.0,
"proteins" : 10.0,
"date" : "0001-01-01"
}, {
"name" : "test",
"fats" : 10.0,
"carbos" : 10.0,
"proteins" : 10.0,
"date" : "2050-06-20"
} ]
} ]
}
6 (other comment)
After discussion, proposed solution:
{
"foodIntakes" : [ {
"name" : "test",
"fats" : 10.0,
"carbos" : 10.0,
"proteins" : 10.0,
"date" : "0001-01-01"
}, {
"name" : "test",
"fats" : 10.0,
"carbos" : 10.0,
"proteins" : 10.0,
"date" : "2050-06-20"
} ]
}
7 (other comment)
For issue #77
8 (other comment)
Thanks for quick fix!!
@guanyz (0 comments)1 (other comment)
Looks good to merge!
@adidoesnt (0 comments)1 (commented on own PR)
Thanks!
@cheunggalen (0 comments)1 (other comment)
Failed CI checks
2 (other comment)
Failed CI tests
3 (other comment)
Failed CI tests
4 (other comment)
Failed CI tests
5 (other comment)
Failed CI tests
6 (other comment)
Failed CI tests
7 (other comment)
Conflicts
8 (other comment)
Failed checkstyle
9 (other comment)
Fail CI tests
10 (other comment)
Failed CI tests
11 (other comment)
Failed CI tests
12 (other comment)
Failed CI tests
13 (other comment)
Pull first then add the date field since the latest commit has passed all the CI checks.
@jessen11 (0 comments)1 (commented on own PR)
I copy this design from the addressbook code,
2 (commented on own PR)
changed
3 (other comment)
Thanks Prof~
4 (other comment)
Decided to push manually due to low number of lines
@GJ0407790 (0 comments)1 (other comment)
@Nanxi-Huang did u pull the latest version before you modify the file, cause right now there seems to be a conflict happening.
2 (other comment)
LGTM
3 (other comment)
Cannot pass the test
4 (other comment)
lgtm
5 (other comment)
lgtm
6 (other comment)
lgtm
7 (other comment)
lgtm
8 (other comment)
Lgtm
9 (other comment)
Seems like my checkstyle not running in DeveloperGuide.md
10 (other comment)
@Andrewzhang217 I never add a new line at EOF in one of my puml file. It's fixed now. Thanks
11 (other comment)
Add a new line at EOF at AddReaderSequenceDiagram.puml should be able to solve the issue
12 (other comment)
lgtm
@branzuelajohn (0 comments)1 (commented on own PR)
I agree, I think the userIDcounter should be implemented perhaps in addressbook instead as certain tests fail currently due to ID not syncing up
2 (commented on own PR)
Thanks for pointing this out! Will amend the code now!
3 (commented on own PR)
This will take in dd/mm/yyyy, dd-mm-yyyy or dd.mm.yyyy and helps validate leap year as well. Do you want me to modify it to only support dd/mm/yyyy?
4 (commented on own PR)
Just male and female
5 (commented on own PR)
Alright i'll edit this. Does this mean that we input the ID of the owner when creating a Dog?
6 (commented on own PR)
I agree, will amend this!
7 (commented on own PR)
Is a set better? Because there is no java implementation of ArraySet
8 (commented on own PR)
Modified it.
9 (commented on own PR)
I agree, will change it!
10 (commented on own PR)
I see, ok will remove these lines!
11 (other comment)
Will create new issue to add tests.
12 (other comment)
I think you can proceed to do the adding and deleting, just that the execution part don't call on model to do the adding, perhaps give a successful response and make use of the gui to get some feedback.
Alright, this is so I can test the classes I just created right?
13 (other comment)
Added DeleteActivityDiagram
14 (other comment)
Added "Navigating the User Guide" section and added symbols to help the reader understand the syntax in the UG
@NightRaven49 (0 comments)1 (other comment)
I agree with your observation, though instead of removing the menu bar outright, I feel that we can replace it with a banner saying History and Response, much like your original UI mockup. We can discuss this tomorrow along with other UI tweaks we can make this coming week.
@shaelynl (0 comments)1 (commented on own PR)
okay i will add that!
2 (commented on own PR)
oh, so we will include finance-related stuff also? okay no prob i will remove number 7!
@gycc7253 (0 comments)1 (other comment)
LGTM
2 (other comment)
lgtm
3 (other comment)
Tutorial no need to merge thx!
4 (other comment)
missed check
@chenzaza (0 comments)1 (other comment)
Fix #26
@VisnuRavi (0 comments)1 (other comment)
Completed and approved
2 (other comment)
LGTM
3 (other comment)
LGTM
4 (other comment)
LGTM
5 (other comment)
Looks great, good job!
@Andrewzhang217 (0 comments)1 (other comment)
As an individual operating a private book loaning service. I can rank least borrowing books, so that I know customers’ preference and reduce importing of those types of books
2 (other comment)
Looks good to me
3 (other comment)
Please fix the checkstyle error before merging to master branch
4 (other comment)
This pull request looks good to me and can be merged to the master branch of our team repository
5 (other comment)
This pull request looks good to me and can be merged into our team repo master branch
@rachelljt (0 comments)1 (commented on own PR)
ohhh okay can i will make the changes
2 (commented on own PR)
okay!
3 (commented on own PR)
ok!
4 (commented on own PR)
ohh i think i pulled this before u merged ur pr... so i dont have the task status class right now.. what shld i do?
5 (commented on own PR)
oh its okay i got it!
6 (commented on own PR)
okay!
@hengyongming (0 comments)1 (commented on own PR)
done
2 (commented on own PR)
done
3 (commented on own PR)
done
4 (other comment)
Should we keep the rest other parts of the DG or delete them since it pertains to AB3?
I think we can just leave it in the meantime and remove it progressively in the future.
5 (other comment)
Some tests are failing, try running tests locally to see whats happening
Yep, I have fixed the error
6 (other comment)
would be good to test if the list of tasks is sorted after reopening the app
I think it is. However, you will need to use the exit command so that the storage saved the latest updated task list
7 (other comment)
LGTM, the command execution only updates the currently active tab right?
Erm I am trying to remodel it such that Users can only edit on the home page. The other tabs are more like viewing the task (completed, expired) etc
@XindiTian (0 comments)1 (commented on own PR)
Ok thanks! I've edited the code
2 (other comment)
Error in commiting, please do not merge
3 (other comment)
Error, please ignore
@Nanxi-Huang (0 comments)1 (other comment)
good edit.
2 (other comment)
lgtm
3 (other comment)
lgtm
4 (other comment)
lgtm
5 (other comment)
looks good to be merged!
6 (other comment)
looks good to be merged into our team repo.
@HuaiZe (0 comments)1 (other comment)
LGTM!
2 (other comment)
LGTM
@wei-yutong (0 comments)1 (commented on own PR)
my bad i put ur link in and it just gave me our team's one so i thought it was the same oops 😅
2 (commented on own PR)
yea i agree that the INDEX_ references are not that necessary
3 (commented on own PR)
ok i'll look into it another time! let's merge this PR first and i ll continue from there onwards 😃
@pasha-292 (0 comments)1 (other comment)
I am merging this PR here, since integrating the Date class with the Person class would mean a lot of work. So, better to keep this part of the work intact, and do the remaining part by generating a new PR.
2 (other comment)
Hi, could anyone tell me why I am failing the test cases?
3 (other comment)
Okay, I passed all test cases and the app runs fine with all the features working after adding Date.
4 (other comment)
I think you need to fix the order of imports for the checkstyle test to pass. Apart from that, is it possible to make the filter command more versatile, by filtering data using other criteria apart from deliveries labelled as done?
5 (other comment)
Also, you need to create test classes for any new class that you create, in order to get the PR to pass all the checks if I'm not wrong. Here is a reference to adding a new command to help you: Adding New Command.
6 (other comment)
I think some of the fields in the StatsCommand class need to be changed to private.
7 (other comment)
For the developer guide and user guide, don't we need to put a screenshot of the commands?
8 (other comment)
Okay, updated developer guide.
9 (other comment)
Changed the title for the developer guide to the previous version before PR 55.
10 (other comment)
Updated the User Guide
11 (other comment)
Enable search by address and remarks.
12 (other comment)
Enabled searching by all customer attributes.
13 (other comment)
Okay, fixed bug
14 (other comment)
I think you need to update the storage files, and also modify the parser tests since most of the issues seem to be from there.
@natosy (0 comments)1 (commented on own PR)
Yes, I was just thinking about that too. Looking at the other methods that were implemented in BudgetBabyLogicManager, I realised that it shouldn't be a problem if I returned a List. Thanks for the suggestion!
2 (other comment)
I think it would be good if you could make this title more specific? Like what aspects of a month in particular? As @eksinyue mentioned, I also feel this PR is similar to #74, solely from the title.
@Jacob-109 (0 comments)1 (other comment)
Could try adding test cases for the stats command to ensure it works well
2 (other comment)
Looks good, maybe you can try to increase the test coverage further
@CharlesLee01 (0 comments)1 (commented on own PR)
I just wanted to leave the hash-tag before the line.
2 (commented on own PR)
Yea, you can refer to our submitted user guide.
3 (commented on own PR)
Mostly formatting issues as far as I can tell, you can just amend your commits and force push to this branch, no need to close and create another pull request. Or maybe you want to do the formatting once after everything is in?
I closed it because idk how to rename the commit message xD.
4 (commented on own PR)
Ok, I will remove it.
5 (commented on own PR)
Yea, I know but the codestyle forces me to do so. Idk why lol
6 (commented on own PR)
I noticed that too
7 (commented on own PR)
Ah, I see! Coz I was trying to make it to look the same with the MESSAGE_UNKNOWN_ENTITY and MESSAGE_UNKNOWN_COMMAND that were used in addressbook.
8 (commented on own PR)
Noted!
9 (commented on own PR)
Noted!
10 (commented on own PR)
Yea, I made it public just for the testing. Does that mean I only have to test public methods that are written?
11 (commented on own PR)
Weird, didn't notice this earlier on. What can I do if something like this pops out?
12 (commented on own PR)
OK, I will check that again. Coz it shows an error of separator wrap which is regarding the brackets.
13 (commented on own PR)
The examples are at the bottom. I did it just like the add and delete command format.
14 (commented on own PR)
I just wanted to make it easier for me to reference the attributes of a program when writing the DG. Forgot to remove it, thx!
15 (commented on own PR)
Can I just remove >>
16 (other comment)
Made the necessary changes.
17 (other comment)
I think we can finalize the formatting in the meeting later. Maybe when we merge, we can just put the parts that others have edited into this.
18 (other comment)
Noted! Sorry for the mails.
19 (other comment)
Sorry, I don't really get you. Can you tell me what's wrong and necessary? I thought I tested on the changes made in your PR?
20 (other comment)
Sync master
21 (other comment)
Ignore this! This is duplicated!
22 (other comment)
I will upload the test cases in another PR when this edit command works yet.